Andy Yan [Mon, 11 Dec 2023 11:57:41 +0000 (19:57 +0800)]
drm/rockchip: vop2: clear afbc en and transform bit for cluster window at linear mode
The enable bit and transform offset of cluster windows should be
cleared when it work at linear mode, or we may have a iommu fault
issue on rk3588 which cluster windows switch between afbc and linear
mode.
As the cluster windows of rk3568 only supports afbc format
so is therefore not affected.
Andy Yan [Mon, 11 Dec 2023 11:57:30 +0000 (19:57 +0800)]
drm/rockchip: vop2: set half_block_en bit in all mode
At first we thought the half_block_en bit in AFBCD_CTRL register
only work in afbc mode. But the fact is that it control the line
buffer in all mode(afbc/tile/linear), so we need configure it in
all case.
As the cluster windows of rk3568 only supports afbc format
so is therefore not affected.
regcache_sync will try to reload the configuration in regcache to
hardware, but the registers of 4 Cluster windows and Esmart1/2/3 on
the upcoming rk3588 can not be set successfully before internal PD
power on.
Also it's better to keep the hardware register as it is before we really
enable it.
So let's revert this version, and keep the first version:
commit afa965a45e01 ("drm/rockchip: vop2: fix suspend/resume")
drm/bridge: ti-sn65dsi86: Associate PWM device to auxiliary device
It's the ti_sn65dsi86.pwm auxiliary driver that creates the pwmchip, so
let the auxiliary device be the parent of the pwm device.
Note that getting a reference to the ti-sn65dsi86's pwm using pwm_get()
isn't affected by this change as ti_sn65dsi86_add_aux_device() sets the
auxiliary device's of_node to that of the main device.
Also change PM runtime tracking and diagnostic messages to use that one.
After enabling runtime PM operation for the auxiliary device, all works
as expected as parent devices are handled just fine.
Elmar Albert [Sat, 9 Dec 2023 06:37:00 +0000 (07:37 +0100)]
drm/panel: simple: Add AUO G156HAN04.0 LVDS display support
G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driver circuit, and LED backlight system. The screen
format is intended to support the 16:9 FHD, 1920(H) x 1080(V) screen
and 16.7M colors (RGB 8-bits) with LED backlight driving circuit.
All input signals are LVDS interface compatible.
G156HAN04.0 is designed for a display unit of notebook style
personal computer and industrial machine.
Document support for the AUO G156HAN04.0 LVDS display.
G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driver circuit, and LED backlight system. The screen
format is intended to support the 16:9 FHD, 1920(H) x 1080(V) screen
and 16.7M colors (RGB 8-bits) with LED backlight driving circuit.
All input signals are LVDS interface compatible.
G156HAN04.0 is designed for a display unit of notebook style
personal computer and industrial machine.
Chris Morgan [Fri, 8 Dec 2023 15:48:45 +0000 (09:48 -0600)]
drm/panel: st7701: Fix AVCL calculation
The AVCL register, according to the datasheet, comes in increments
of -0.2v between -4.4v (represented by 0x0) to -5.0v (represented
by 0x3). The current calculation is done by adding the defined
AVCL value in mV to -4400 and then dividing by 200 to get the register
value. Unfortunately if I subtract -4400 from -4400 I get -8800, which
divided by 200 gives me -44. If I instead subtract -4400 from -4400
I get 0, which divided by 200 gives me 0. Based on the datasheet this
is the expected register value.
John Watts [Sun, 10 Dec 2023 06:55:51 +0000 (17:55 +1100)]
drm/panel: nv3052c: Allow specifying registers per panel
Panel initialization registers are per-display and not tied to the
controller itself. Different panels will specify their own registers.
Attach the sequences to the panel info struct so future panels
can specify their own sequences.
drm/vkms: move wb's atomic_check from encoder to connector
As the renamed drm_atomic_helper_check_wb_connector_state() now accepts
drm_writeback_connector as the first argument (instead of drm_encoder),
move the VKMS writeback atomic_check from drm_encoder_helper_funcs to
drm_connector_helper_funcs. Also drop the vkms_wb_encoder_helper_funcs,
which have become empty now.
The drm_atomic_helper_check_wb_encoder_state() function doesn't use
encoder for anything other than getting the drm_device instance. The
function's description talks about checking the writeback connector
state, not the encoder state. Moreover, there is no such thing as an
encoder state, encoders generally do not have a state on their own.
Rename the function to drm_atomic_helper_check_wb_connector_state()
and change arguments to drm_writeback_connector and drm_atomic_state.
Rob Herring [Thu, 7 Dec 2023 16:25:00 +0000 (10:25 -0600)]
drm/bridge: aux-hpd: Replace of_device.h with explicit include
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. Soon the implicit includes are going to be removed.
of_device.h isn't needed, but of.h is for of_node_put().
Rodrigo Vivi [Fri, 1 Dec 2023 04:21:54 +0000 (23:21 -0500)]
drm/doc/rfc: Move userptr integration and vm_bind to the 'completed' section
The must-have part of the documentation was already added to the existing
/gpu/drm-vm-bind-async. The other extra discussion around GPUVM helpers
are currently active in the community. None of those discussion should
block Xe since documentation, specially around locking was completed in
a community consensus.
Rodrigo Vivi [Fri, 1 Dec 2023 04:21:52 +0000 (23:21 -0500)]
drm/doc/rfc: Mark drm_scheduler as completed
Current drm-xe-next doesn't have any drm/scheduler patch that is not
already accepted in drm-misc-next. This completed this goal with
the consensus of how the drm/scheduler fits to the fw scheduling and
the relationship between drm_gpu_scheduler and drm_sched_entity.
Matthew Brost [Fri, 1 Dec 2023 04:21:51 +0000 (23:21 -0500)]
drm/doc/rfc: Mark long running workload as complete.
No DRM scheduler changes required, drivers just return NULL in run_job
vfunc.
The rough consensus is that no helper or extra scaffolding is needed
around long-running jobs and no further changes to drm-scheduler.
At least for now. Other drivers that currently do long-running workloads
have no plat to use drm-scheduler. Besides, the current consensus is
that this solution of simply returning NULL to the run_job function should
work without extra code duplication or complication.
On top of that, this item was already a non-blocking one for upstreaming Xe,
so let's move that to the 'Completed' section and revisit the long-running
solution as a community after Xe is integrated in DRM.
encoder->funcs entry might be NULL, so check it first before calling its
methods. This fixes NULL pointer dereference observed on Rasberry Pi
3b/4b boards.
drm/bridge: Return NULL instead of plain 0 in drm_dp_hpd_bridge_register() stub
sparse complains:
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c: note: in included file:
include/drm/bridge/aux-bridge.h:29:16: sparse: sparse: Using plain integer as NULL pointer
usb: typec: qcom-pmic-typec: Only select DRM_AUX_HPD_BRIDGE with OF
CONFIG_DRM_AUX_HPD_BRIDGE depends on CONFIG_OF but that dependency is
not included when CONFIG_TYPEC_QCOM_PMIC selects it, resulting in a
Kconfig warning when CONFIG_OF is disabled:
WARNING: unmet direct dependencies detected for DRM_AUX_HPD_BRIDGE
Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && OF [=n]
Selected by [m]:
- TYPEC_QCOM_PMIC [=m] && USB_SUPPORT [=y] && TYPEC [=m] && TYPEC_TCPM [=m] && (ARCH_QCOM || COMPILE_TEST [=y]) && (DRM [=m] || DRM [=m]=n) && DRM_BRIDGE [=y]
Only select CONFIG_DRM_AUX_HPD_BRIDGE with both CONFIG_DRM_BRIDGE and
CONFIG_OF to clear up the warning.
usb: typec: nb7vpq904m: Only select DRM_AUX_BRIDGE with OF
CONFIG_DRM_AUX_BRIDGE depends on CONFIG_OF but that dependency is not
included when CONFIG_TYPEC_MUX_NB7VPQ904M selects it, resulting in a
Kconfig warning when CONFIG_OF is disabled:
WARNING: unmet direct dependencies detected for DRM_AUX_BRIDGE
Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && OF [=n]
Selected by [y]:
- TYPEC_MUX_NB7VPQ904M [=y] && USB_SUPPORT [=y] && TYPEC [=y] && I2C [=y] && (DRM [=y] || DRM [=y]=n) && DRM_BRIDGE [=y]
Only select CONFIG_DRM_AUX_BRIDGE with both CONFIG_DRM_BRIDGE and
CONFIG_OF to clear up the warning.
After reading the code, I think this is what happens:
We have a DSI host defined in the device tree and a DSI peripheral under
that host (i.e. an i2c device using the DSI as data bus doesn't exhibit
this behavior).
The host driver calls mipi_dsi_host_register(), which causes (via a few
functions) mipi_dsi_device_add() to be called for the DSI peripheral. So
now we have a DSI device under the host, but attach hasn't been called.
Normally the probing of the devices continues, and eventually the DSI
peripheral's driver will call mipi_dsi_attach(), attaching the
peripheral.
However, if the host driver's probe encounters an error after calling
mipi_dsi_host_register(), and before the peripheral has called
mipi_dsi_attach(), the host driver will do cleanups and return an error
from its probe function. The cleanups include calling
mipi_dsi_host_unregister().
mipi_dsi_host_unregister() will call two functions for all its DSI
peripheral devices: mipi_dsi_detach() and mipi_dsi_device_unregister().
The latter makes sense, as the device exists, but the former may be
wrong as attach has not necessarily been done.
To fix this, track the attached state of the peripheral, and only detach
from mipi_dsi_host_unregister() if the peripheral was attached.
Note that I have only tested this with a board with an i2c DSI
peripheral, not with a "pure" DSI peripheral.
However, slightly related, the unregister machinery still seems broken.
E.g. if the DSI host driver is unbound, it'll detach and unregister the
DSI peripherals. After that, when the DSI peripheral driver unbound
it'll call detach either directly or using the devm variant, leading to
a crash. And probably the driver will crash if it happens, for some
reason, to try to send a message via the DSI bus.
Tomi Valkeinen [Fri, 3 Nov 2023 13:14:04 +0000 (15:14 +0200)]
drm/framebuffer: Fix use of uninitialized variable
smatch reports:
drivers/gpu/drm/drm_framebuffer.c:654 drm_mode_getfb2_ioctl() error: uninitialized symbol 'ret'.
'ret' is possibly not set when there are no errors, causing the error
above. I can't say if that ever happens in real-life, but in any case I
think it is good to initialize 'ret' to 0.
Tomi Valkeinen [Fri, 3 Nov 2023 13:14:03 +0000 (15:14 +0200)]
drm/drm_file: fix use of uninitialized variable
smatch reports:
drivers/gpu/drm/drm_file.c:967 drm_show_memory_stats() error: uninitialized symbol 'supported_status'.
'supported_status' is only set in one code path. I'm not familiar with
the code to say if that path will always be ran in real life, but
whether that is the case or not, I think it is good to initialize
'supported_status' to 0 to silence the warning (and possibly fix a bug).
Dan Carpenter [Wed, 6 Dec 2023 15:05:15 +0000 (18:05 +0300)]
drm/bridge: nxp-ptn3460: simplify some error checking
The i2c_master_send/recv() functions return negative error codes or
they return "len" on success. So the error handling here can be written
as just normal checks for "if (ret < 0) return ret;". No need to
complicate things.
Btw, in this code the "len" parameter can never be zero, but even if
it were, then I feel like this would still be the best way to write it.
Fixes: 914437992876 ("drm/bridge: nxp-ptn3460: fix i2c_master_send() error checking") Suggested-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/04242630-42d8-4920-8c67-24ac9db6b3c9@moroto.mountain
Donald Robson [Mon, 4 Dec 2023 15:13:37 +0000 (15:13 +0000)]
drm/imagination: Removed unused functions in pvr_fw_trace
Fixing the warning below due to an unused file level vtable. Removing
only this causes additional warnings for the now unused functions, so
I've removed those too.
>> drivers/gpu/drm/imagination/pvr_fw_trace.c:205:37: warning: 'pvr_fw_trace_group_mask_fops' defined but not used [-Wunused-const-variable=]
205 | static const struct file_operations pvr_fw_trace_group_mask_fops = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Changes since v1:
- Corrected hash in Fixes tag.
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311302054.MVYPxFCE-lkp@intel.com/ Fixes: cb56cd610866 ("drm/imagination: Add firmware trace to debugfs") Signed-off-by: Donald Robson <donald.robson@imgtec.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231204151337.60930-1-donald.robson@imgtec.com
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
drm/simpledrm: Do not include <drm/drm_plane_helper.h>
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
drm/ofdrm: Do not include <drm/drm_plane_helper.h>
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
drm/solomon: Do not include <drm/drm_plane_helper.h>
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
drm/shmobile: Do not include <drm/drm_plane_helper.h>
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
drm/loongson: Do not include <drm/drm_plane_helper.h>
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
drm/amdgpu: Do not include <drm/drm_plane_helper.h>
Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.
The AGP subsystem supports a user-space interface via /dev/agpgart. It
is only enabled with DRM support for mode setting in user space. (i.e.,
CONFIG_DRM_LEGACY). All of that DRM code has been removed and the option
will go away. Hence remove the AGP frontend.
Modern DRM drivers with kernel mode setting handle AGP support internally.
drm: Remove locking for legacy ioctls and DRM_UNLOCKED
Modern DRM drivers acquire ioctl locks by themselves. Legacy ioctls
for user-space mode setting used to acquire drm_global_mutex. After
removing the ioctl entry points, also remove the locking code. The only
legacy ioctl without global locking was VBLANK_WAIT, which has been
removed as well. Hence remove the related DRM_UNLOCKED flag.
Remove all hooks and calls into code for user-space mode setting from
the DRM core. Without the drivers and ioctl entry points, none of this
is required any longer.
drm: Remove the legacy DRM_IOCTL_MODESET_CTL ioctl
DRM drivers with user-space mode setting have been removed in Linux
v6.3. [1] Now remove the ioctl entry points for these drivers. Invoking
any of the ioctl ops will unconditionally return -EINVAL to user space.
Invoking DRM_IOCTL_MODESET_CTL is different from the other legacy
ioctl ops as it returns 0 even without CONFIG_DRM_LEGACY set. From the
original commit 29935554b384 ("drm: Disallow DRM_IOCTL_MODESET_CTL for
KMS drivers") it is not apparent how or why the operation differs from
the others. It is likely just an oversight in commit 61ae227032e7
("drm: allow removal of legacy codepaths (v4.1)"), which allowed
disabling leagacy ioctls in the first place. Still keep this removal
separate from the other ioctls to allow an easy revert, if necessary.
DRM drivers with user-space mode setting have been removed in Linux
v6.3. [1] Now remove the ioctl entry points for these drivers. Invoking
any of the ioctl ops will unconditionally return -EINVAL to user space.
This has already been the behavior for kernels without CONFIG_DRM_LEGACY
set.
The drm_atomic_print_new_state() already prints private object state via
drm_atomic_private_obj_print_state(). Add private object state dumping
to __drm_state_dump(), so that it is also included into drm_state_dump()
output and into debugfs/dri/N/state file.
Boris Brezillon [Mon, 4 Dec 2023 15:14:06 +0000 (16:14 +0100)]
drm/gpuvm: Let drm_gpuvm_bo_put() report when the vm_bo object is destroyed
Some users need to release resources attached to the vm_bo object when
it's destroyed. In Panthor's case, we need to release the pin ref so
BO pages can be returned to the system when all GPU mappings are gone.
This could be done through a custom drm_gpuvm::vm_bo_free() hook, but
this has all sort of locking implications that would force us to expose
a drm_gem_shmem_unpin_locked() helper, not to mention the fact that
having a ::vm_bo_free() implementation without a ::vm_bo_alloc() one
seems odd. So let's keep things simple, and extend drm_gpuvm_bo_put()
to report when the object is destroyed.
drm/panfrost: Synchronize and disable interrupts before powering off
To make sure that we don't unintentionally perform any unclocked and/or
unpowered R/W operation on GPU registers, before turning off clocks and
regulators we must make sure that no GPU, JOB or MMU ISR execution is
pending: doing that requires to add a mechanism to synchronize the
interrupts on suspend.
Add functions panfrost_{gpu,job,mmu}_suspend_irq() which will perform
interrupts masking and ISR execution synchronization, and then call
those in the panfrost_device_runtime_suspend() handler in the exact
sequence of job (may require mmu!) -> mmu -> gpu.
As a side note, JOB and MMU suspend_irq functions needed some special
treatment: as their interrupt handlers will unmask interrupts, it was
necessary to add an `is_suspended` bitmap which is used to address the
possible corner case of unintentional IRQ unmasking because of ISR
execution after a call to synchronize_irq().
At resume, clear each is_suspended bit in the reset path of JOB/MMU
to allow unmasking the interrupts.
drm/panfrost: Add gpu_irq, mmu_irq to struct panfrost_device
In preparation for adding a IRQ synchronization mechanism for PM suspend,
add gpu_irq and mmu_irq variables to struct panfrost_device and change
functions panfrost_gpu_init() and panfrost_mmu_init() to use those.
drm/panfrost: Ignore core_mask for poweroff and disable PWRTRANS irq
Some SoCs may be equipped with a GPU containing two core groups
and this is exactly the case of Samsung's Exynos 5422 featuring
an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
is partial, as this driver currently supports using only one
core group and that's reflected on all parts of it, including
the power on (and power off, previously to this patch) function.
The issue with this is that even though executing the soft reset
operation should power off all cores unconditionally, on at least
one platform we're seeing a crash that seems to be happening due
to an interrupt firing which may be because we are calling power
transition only on the first core group, leaving the second one
unchanged, or because ISR execution was pending before entering
the panfrost_gpu_power_off() function and executed after powering
off the GPU cores, or all of the above.
Finally, solve this by:
- Avoid to enable the power transition interrupt on reset; and
- Ignoring the core_mask and ask the GPU to poweroff both core groups
Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()") Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231204114215.54575-2-angelogioacchino.delregno@collabora.com
Timings taken from the datasheet, although sometimes there are just
typical values and it's not clear if they are no min and max values or
if you must use the typical value exactly. To make things worse, there
is no back porch but only a combined sync and back porch length.
Unfortunately, there is not public datasheet. Therefore, here are the
relevant timings:
| min | typ | max |
-----------------+-----+--------+-----+
CLK frequency | - | 25.175 | - |
HS period | - | 800 | - |
HS pulse width | 5 | 30 | - |
HS-DEN time | 112 | 144 | 175 |
DEN pulse width | - | 640 | - |
VS pulse width | 1 | 3 | 5 |
VS-DEN time | - | 35 | - |
VS period | - | 525 | - |
Marco Felsch [Thu, 23 Nov 2023 17:08:04 +0000 (18:08 +0100)]
drm/panel: ilitek-ili9881c: make use of prepare_prev_first
The panel.prepare() call requires an initialized MIPI-DSI host, so set
the prepare_prev_first flag to indicate that the host must be
initialized first.
Chris Morgan [Mon, 4 Dec 2023 18:57:15 +0000 (12:57 -0600)]
drm/panel: himax-hx8394: Add Support for Powkiddy X55 panel
Add support for the Powkiddy X55 panel as used on the Powkiddy X55
handheld gaming console. This panel uses a Himax HX8394 display
controller and requires a vendor provided init sequence. The display
resolution is 720x1280 and is 67mm by 121mm as measured with calipers.
Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.
Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.
Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.
Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.
Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.
Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.
Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.
drm/bridge: migrate bridge_chains to per-encoder file
Instead of having a single file with all bridge chains, list bridges
under a corresponding per-encoder debugfs directory.
While we are at it, also slightly improve the formatting of the bridge
data: split a single line entry into multiple lines, include the symbol
name of the bridge funcs and add the textual representation of the
bridge ops.
Each of connectors and CRTCs used by the DRM device provides debugfs
directory, which is used by several standard debugfs files and can
further be extended by the driver. Add such generic debugfs directories
for encoder.
projects / mirror_ubuntu-kernels.git / log