Jouni Högander [Wed, 14 Jun 2023 05:17:31 +0000 (08:17 +0300)]
drm/i915/fbc: Moved fence related code away from intel_fbc
As a preparation for Xe move HW fence details away from intel_fbc code.
Add new functions to check support for legacy fencing and fence id and use
these in fbc code. Xe doesn't support legacy fencing.
Jouni Högander [Wed, 14 Jun 2023 05:17:30 +0000 (08:17 +0300)]
drm/i915/fbc: Make FBC check stolen at use time
As a preparation for Xe change stolen memory initialization check to be
done in use-time instead of during initialization.
In case of xe, stolen memory is initialised much later so it can't be
checked during init. There is no specific reason to check this in init for
i915 either -> perform the check in use-time. This also gives us benefit
fbc_no_reason reporting missing initialization being reason for disabled
fbc.
Jouni Högander [Wed, 14 Jun 2023 05:17:29 +0000 (08:17 +0300)]
drm/i915: Move stolen memory handling into i915_gem_stolen
We are preparing for Xe. Xe stolen memory handling differs from i915 so we
want to move stolen memory handling details into i915_gem_stolen.
Also add a common type for fbc compressed fb and use it from fbc code
instead of underlying type directly. This way we can have common type
i915_stolen_fb for both i915 and Xe.
Dave Airlie [Mon, 7 Aug 2023 03:49:24 +0000 (13:49 +1000)]
Merge tag 'drm-intel-gt-next-2023-08-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
Driver Changes:
- Avoid infinite GPU waits by avoidin premature release of request's
reusable memory (Chris, Janusz)
- Expose RPS thresholds in sysfs (Tvrtko)
- Apply GuC SLPC min frequency softlimit correctly (Vinay)
- Restore SLPC efficient freq earlier (Vinay)
- Consider OA buffer boundary when zeroing out reports (Umesh)
- Extend Wa_14015795083 to TGL, RKL, DG1 and ADL (Matt R)
- Fix context workarounds with non-masked regs on MTL/DG2 (Lucas)
- Enable the CCS_FLUSH bit in the pipe control and in the CS for MTL+ (Andi)
- Update MTL workarounds 14018778641, 22016122933 (Tejas, Zhanjun)
- Ensure memory quiesced before AUX CCS invalidation (Jonathan)
- Add a gsc_info debugfs (Daniele)
- Invalidate the TLBs on each GT on multi-GT device (Chris)
- Fix a VMA UAF for multi-gt platform (Nirmoy)
- Do not use stolen on MTL due to HW bug (Nirmoy)
- Check HuC and GuC version compatibility on MTL (Daniele)
- Dump perf_limit_reasons for slow GuC init debug (Vinay)
- Replace kmap() with kmap_local_page() (Sumitra, Ira)
- Add sentinel to xehp_oa_b_counters for KASAN (Andrzej)
- Add the gen12_needs_ccs_aux_inv helper (Andi)
- Fixes and updates for GSC memory allocation (Daniele)
- Fix one wrong caching mode enum usage (Tvrtko)
- Fixes for GSC wakeref (Alan)
- Static checker fixes (Harshit, Arnd, Dan, Cristophe, David, Andi)
- Rename flags with bit_group_X according to the datasheet (Andi)
- Use direct alias for i915 in requests (Andrzej)
- Replace i915->gt0 with to_gt(i915) (Andi)
- Use the i915_vma_flush_writes helper (Tvrtko)
- Selftest improvements (Alan)
- Remove dead code (Tvrtko)
Dave Airlie [Mon, 7 Aug 2023 03:18:12 +0000 (13:18 +1000)]
Merge tag 'drm-intel-next-2023-08-03' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- Removing unused declarations (Arnd, Gustavo)
- ICL+ DSI modeset sequence fixes (Ville)
- Improvements on HDCP (Suraj)
- Fixes and clean up on MTL Display (Mika Kahola, Lee, RK, Nirmoy, Chaitanya)
- Restore HSW/BDW PSR1 (Ville)
- Other PSR Fixes (Jouni)
- Fixes around DC states and other Display Power (Imre)
- Init DDI ports in VBT order (Ville)
- General documentation fixes (Jani)
- General refactor for better organization (Jani)
- Bigjoiner fix (Stanislav)
- VDSC Fixes and improvements (Stanialav, Suraj)
- Hotplug fixes and improvements (Simon, Suraj)
- Start using plane scale factor for relative data rate (Stanislav)
- Use shmem for dpt objects (RK)
- Simplify expression &to_i915(dev)->drm (Uwe)
- Do not access i915_gem_object members from frontbuffer tracking (Jouni)
- Fix uncore race around i915->params.mmio_debug (Jani)
Dave Airlie [Mon, 7 Aug 2023 01:00:32 +0000 (11:00 +1000)]
Merge tag 'drm-misc-next-2023-08-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v6.6:
UAPI Changes:
* virtio:
* Support sync objects
Cross-subsystem Changes:
* dt-bindings:
* Move several panel bindings to the correct files
* fbcon:
* Cleanups
* fbdev:
* Use _IOMEM_, _SYSMEM_, _DMAMEM_ infixes for initializer macros
and Kconfig tokens, update drivers accordingly
* ps3fb: Build fix
* hid/i2c:
* Allow panels and touchscreens to power sequence together
* host1x:
* Fixes
* video:
* Fix Kconfig dependencies for boot-up logo
Core Changes:
* Documentation updates and fixes
* Fixes
* MIPI-DBI:
* Allow using same the D/C GPIO for multiple displays plus
driver updates
* Tests:
* Convert to kunit actions
* Fix NULL-deref in drm_exec tests
Driver Changes:
* armada:
* Fixes
* ast:
* Represent BMV as virtual connector
* Report DP connection status
* bridge:
* dw-hdmi: Support CEC suspend/resume
* Support debugfs for chains
* Fixes
* i915:
* Fixes
* imx:
* Convert to dev_error_probe()
* Cleanups
* ipu-v3:
* Convert to devm_platform_ioremap_resource() in several places
* nouveau:
* Workaround DPCD issues
* panel:
* Convert to of_device_get_match_data()
* Fix Kconfig dependencies
* simple: Set bpc value to fix warning; Set connector type for AUO T215HVN01;
Support Innolux G156HCE-L01 plus DT bindings
* ili9881: Support TDO TL050HDV35 LCD panel plus DT bindings
* startek: Support KD070FHFID015 MIPI-DSI panel plus DT bindings
* sitronix-st7789v: Support Inanbo T28CP45TN89 plus DT bindings;
Support EDT ET028013DMA plus DT bindings; Various cleanups
* edp: Add timings for N140HCA-EAC
* Allow panels and touchscreens to power sequence together
* Documentation fixes
Jani Nikula [Thu, 3 Aug 2023 12:27:06 +0000 (15:27 +0300)]
drm/i915/sdvo: fix panel_type initialization
Commit 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT
declares an explicit panel type") started using -1 as the value for
unset panel_type. It gets initialized in intel_panel_init_alloc(), but
the SDVO code never calls it.
Call intel_panel_init_alloc() to initialize the panel, including the
panel_type.
Reported-by: Tomi Leppänen <tomi@tomin.site> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8896 Fixes: 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.1+ Reviewed-by: Uma Shankar <uma.shankar@intel.com> Tested-by: Tomi Leppänen <tomi@tomin.site> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230803122706.838721-1-jani.nikula@intel.com
Merge conflicts:
- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
The switch to drm eu helpers in 8a206685d36f ("drm/amdgpu: use
drm_exec for GEM and CSA handling v2") clashed with the
cosmetic cleanups from 30953c4d000b ("drm/amdgpu: Fix style
issues in amdgpu_gem.c"). I
kept the former since the cleanup up code is gone.
- drivers/gpu/drm/amd/amdgpu/atom.c. adf64e214280 ("drm/amd: Avoid reading the VBIOS part number
twice") removed code that 992b8fe106ab ("drm/radeon: Replace
all non-returning strlcpy with strscpy") polished.
Arnd Bergmann [Wed, 2 Aug 2023 12:49:40 +0000 (14:49 +0200)]
HID: i2c-hid: add more DRM dependencies
When a symbol is selected that has extra dependencies,
anything that selects it must have the same dependencies.
With the added CONFIG_DRM reference from I2C_HID_CORE,
this broke a couple of drivers that now also depend
on DRM:
WARNING: unmet direct dependencies detected for I2C_HID_CORE
Depends on [m]: HID_SUPPORT [=y] && I2C_HID [=y] && (DRM [=m] || !DRM [=m])
Selected by [y]:
- I2C_HID_OF [=y] && HID_SUPPORT [=y] && I2C_HID [=y]
- I2C_HID_ACPI [=y] && HID_SUPPORT [=y] && I2C_HID [=y] && ACPI [=y]
- I2C_HID_OF_GOODIX [=y] && HID_SUPPORT [=y] && I2C_HID [=y] && OF [=y]
x86_64-linux-ld: vmlinux.o: in function `i2c_hid_core_remove':
(.text+0xfc8826): undefined reference to `drm_panel_remove_follower'
x86_64-linux-ld: vmlinux.o: in function `i2c_hid_core_probe':
(.text+0xfc8da0): undefined reference to `drm_is_panel_follower'
Add the corresponding DRM||!DRM dependencies on each one that
is affected.
Use fb_info() to print status message at the end of the probe function,
which avoids decoding the devices. fb_info() works with or without an
fbdev kernel device. Fixes the following error:
../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe':
../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no member named 'dev'
1172 | dev_driver_string(info->dev), dev_name(info->dev),
| ^~
../include/linux/dev_printk.h:110:37: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~~~~~~~~~
../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n",
| ^~~~~~~~
../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no member named 'dev'
1172 | dev_driver_string(info->dev), dev_name(info->dev),
| ^~
../include/linux/dev_printk.h:110:37: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~~~~~~~~~
../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n",
| ^~~~~~~~
Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/lkml/ccc63065-2976-88ef-1211-731330bf2866@infradead.org/ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 701d2054fa31 ("fbdev: Make support for userspace interfaces configurable") Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Helge Deller <deller@gmx.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Bagas Sanjaya <bagasdotme@gmail.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Link: https://patchwork.freedesktop.org/patch/msgid/20230731175535.11345-1-tzimmermann@suse.de
Simon Ser [Wed, 12 Jul 2023 18:32:00 +0000 (18:32 +0000)]
drm/doc: document that PRIME import/export is always supported
Since commit 6b85aa68d9d5 ("drm: Enable PRIME import/export for all
drivers"), import/export is always supported. Document this so that
user-space knows what to expect.
Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Jeffrey Hugo <quic_jhugo@quicinc.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230712183156.191445-1-contact@emersion.fr
CEC interrupt status/mask and logical address registers
will be reset when device enter suspend.
It will cause cec fail to work after device resume.
Add CEC suspend/resume functions, reinitialize logical address registers
and restore interrupt status/mask registers after resume.
Add support for Innolux G156HCE-L01 15.6" 1920x1080 24bpp
dual-link LVDS TFT panel. Documentation is available at [1].
The middle frequency is tuned slightly upward from 70.93 MHz
to 72 MHz, otherwise the panel shows slight flicker.
drm/panel: Fix todo indentation for panel prepared/enabled cleanup
In commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled
in drm_panel") the formatting for a code block was not quite
right. This caused an error when building htmldocs:
Fix the error by using the proper syntax for a code block.
Fixes: d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20230802141724.0edce253@canb.auug.org.au Signed-off-by: Douglas Anderson <dianders@chromium.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/20230802074727.2.Iaeb7b0f7951aee6b8c090364bbc87b1ae198a857@changeid
drm/panel: Fix kernel-doc typo for `follower_lock`
In the kernel doc for the `follower_lock` member of `struct drm_panel`
there was a typo where it was called `followers_lock`. This resulted
in a warning when making "htmldocs":
./include/drm/drm_panel.h:270: warning:
Function parameter or member 'follower_lock' not described in 'drm_panel'
Fix the typo.
Fixes: de0874165b83 ("drm/panel: Add a way for other devices to follow panel state") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20230802142136.0f67b762@canb.auug.org.au Signed-off-by: Douglas Anderson <dianders@chromium.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/20230802074727.1.I4036706ad5e7f45e80d41b777164258e52079cd8@changeid
This should be done before the soft min/max frequencies are restored.
When we disable the "Ignore efficient frequency" flag, GuC does not
actually bring the requested freq down to RPn.
Specifically, this scenario-
- ignore efficient freq set to true
- reduce min to RPn (from efficient)
- suspend
- resume (includes GuC load, restore soft min/max, restore efficient freq)
- validate min freq has been resored to RPn
This will fail if we didn't first restore(disable, in this case) efficient
freq flag before setting the soft min frequency.
v2: Bring the min freq down to RPn when we disable efficient freq (Rodrigo)
Also made the change to set the min softlimit to RPn at init. Otherwise, we
were storing RPe there.
Colin Ian King [Wed, 26 Jul 2023 14:06:26 +0000 (15:06 +0100)]
accel/qaic: remove redundant pointer pexec
Pointer pexec is being assigned a value however it is never read. The
assignment is redundant and can be removed. Replace sizeof(*pexec)
with sizeof the type and remove the declaration of pointer pexec.
Otto Pflüger [Mon, 24 Jul 2023 06:56:54 +0000 (08:56 +0200)]
drm/tiny: panel-mipi-dbi: Allow sharing the D/C GPIO
Displays that are connected to the same SPI bus may share the D/C GPIO.
Use GPIOD_FLAGS_BIT_NONEXCLUSIVE to allow access to the same GPIO for
multiple panel-mipi-dbi instances. Exclusive access to the GPIO during
transfers is ensured by the locking in drm_mipi_dbi.c.
Otto Pflüger [Mon, 24 Jul 2023 06:56:53 +0000 (08:56 +0200)]
drm/mipi-dbi: Lock SPI bus before setting D/C GPIO
Multiple displays may be connected to the same bus and share a D/C GPIO,
so the display driver needs exclusive access to the bus to ensure that
it can control the D/C GPIO safely.
Tomi Valkeinen [Wed, 2 Aug 2023 07:04:11 +0000 (10:04 +0300)]
drm/bridge: Add debugfs print for bridge chains
DRM bridges are not visible to the userspace and it may not be
immediately clear if the chain is somehow constructed incorrectly. I
have had two separate instances of a bridge driver failing to do a
drm_bridge_attach() call, resulting in the bridge connector not being
part of the chain. In some situations this doesn't seem to cause issues,
but it will if DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is used.
Add a debugfs file to print the bridge chains. For me, on this TI AM62
based platform, I get the following output:
Li Zetao [Tue, 1 Aug 2023 08:32:20 +0000 (16:32 +0800)]
drm: xlnx: zynqmp_dpsub: Use devm_platform_ioremap_resource_byname()
Convert platform_get_resource_byname() + devm_ioremap_resource() to a
single call to devm_platform_ioremap_resource_byname(), as this is
exactly what this function does.
Wang Ming [Wed, 26 Jul 2023 11:57:56 +0000 (19:57 +0800)]
drm: xlnx: zynqmp_dpsub: Use dev_err_probe instead of dev_err
It is possible that dma_request_chan() returns EPROBE_DEFER, in which
case the driver defers probing without printing any message. Use
dev_err_probe() to record the probe deferral cause and ease debugging.
Signed-off-by: Wang Ming <machel@vivo.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Douglas Anderson [Thu, 27 Jul 2023 17:16:37 +0000 (10:16 -0700)]
HID: i2c-hid: Do panel follower work on the system_wq
Turning on an i2c-hid device can be a slow process. This is why
i2c-hid devices use PROBE_PREFER_ASYNCHRONOUS. Unfortunately, when
we're a panel follower the i2c-hid power up sequence now blocks the
power on of the panel. Let's fix that by scheduling the work on the
system_wq.
Douglas Anderson [Thu, 27 Jul 2023 17:16:36 +0000 (10:16 -0700)]
HID: i2c-hid: Support being a panel follower
As talked about in the patch ("drm/panel: Add a way for other devices
to follow panel state"), we really want to keep the power states of a
touchscreen and the panel it's attached to in sync with each other. In
that spirit, add support to i2c-hid to be a panel follower. This will
let the i2c-hid driver get informed when the panel is powered on and
off. From there we can match the i2c-hid device's power state to that
of the panel.
NOTE: this patch specifically _doesn't_ use pm_runtime to keep track
of / manage the power state of the i2c-hid device, even though my
first instinct said that would be the way to go. Specific problems
with using pm_runtime():
* The initial power up couldn't happen in a runtime resume function
since it create sub-devices and, apparently, that's not good to do
in your resume function.
* Managing our power state with pm_runtime meant fighting to make the
right thing happen at system suspend to prevent the system from
trying to resume us only to suspend us again. While this might be
able to be solved, it added complexity.
Overall the code without pm_runtime() ended up being smaller and
easier to understand.
Douglas Anderson [Thu, 27 Jul 2023 17:16:35 +0000 (10:16 -0700)]
HID: i2c-hid: Suspend i2c-hid devices in remove
In the i2c-hid remove() function we currently try to power off,
depopulate our child device, and free our resources. That's OK, but...
* If the i2c-hid device is on a power rail that can't turn off (either
an always-on or a shared power rail) we won't try to put the device
in a low power state during remove(). This probably doesn't matter
for very many devices but it could be nice in some instances.
* If the i2c-hid device somehow manages to generate an interrupt after
we tried to power off it is conceivable that the interrupt could
arrive during or after the call to hid_destroy_device() but before
the call to free_irq(). That could cause a crash since our IRQ
handler isn't expecting it. One could imagine this happening in
the case where we couldn't turn off (see the previous bullet) or,
possibly, if the interrupt line could glitch shortly after the
device powered off.
Let's call the suspend code during remove to avoid these issues. That
will put the device into a low power state and also disable
interrupts.
Technically, one could consider this a "fix" of commit 4a200c3b9a40
("HID: i2c-hid: introduce HID over i2c specification implementation").
However, since the above bullet points are more theoretical than
problems seen on real systems and since the remove() of an i2c-hid
touchscreen isn't terribly likely to be called in production, it's
probably not worth the bother of trying to backport it.
Douglas Anderson [Thu, 27 Jul 2023 17:16:34 +0000 (10:16 -0700)]
HID: i2c-hid: Make suspend and resume into helper functions
In a future patch we'd like to be able to call the current i2c-hid
suspend and resume functions from times other than system
suspend. Move the functions higher up in the file and have them take a
"struct i2c_hid" to make this simpler. We'll then add tiny wrappers of
the functions for use with system suspend.
This change is expected to have no functional effect.
Douglas Anderson [Thu, 27 Jul 2023 17:16:33 +0000 (10:16 -0700)]
HID: i2c-hid: Rearrange probe() to power things up later
In a future patch, we want to change i2c-hid not to necessarily power
up the touchscreen during probe. In preparation for that, rearrange
the probe function so that we put as much stuff _before_ powering up
the device as possible.
This change is expected to have no functional effect.
Douglas Anderson [Thu, 27 Jul 2023 17:16:32 +0000 (10:16 -0700)]
HID: i2c-hid: Switch to SYSTEM_SLEEP_PM_OPS()
The SYSTEM_SLEEP_PM_OPS() allows us to get rid of '#ifdef
CONFIG_PM_SLEEP', as talked about in commit 1a3c7bb08826 ("PM: core:
Add new *_PM_OPS macros, deprecate old ones").
This change is expected to have no functional effect.
Douglas Anderson [Thu, 27 Jul 2023 17:16:30 +0000 (10:16 -0700)]
drm/panel: Add a way for other devices to follow panel state
These days, it's fairly common to see panels that have touchscreens
attached to them. The panel and the touchscreen can somewhat be
thought of as totally separate devices and, historically, this is how
Linux has treated them. However, treating them as separate isn't
necessarily the best way to model the two devices, it was just that
there was no better way. Specifically, there is little practical
reason to have the touchscreen powered on when the panel is turned
off, but if we model the devices separately we have no way to keep the
two devices' power states in sync with each other.
The issue described above makes it sound as if the problem here is
just about efficiency. We're wasting power keeping the touchscreen
powered up when the screen is off. While that's true, the problem can
go deeper. Specifically, hardware designers see that there's no reason
to have the touchscreen on while the screen is off and then build
hardware assuming that software would never turn the touchscreen on
while the screen is off.
In the very simplest case of hardware designs like this, the
touchscreen and the panel share some power rails. In most cases, this
turns out not to be terrible and is, again, just a little less
efficient. Specifically if we tell Linux that the touchscreen and the
panel are using the same rails then Linux will keep the rails on when
_either_ device is turned on. That ends to work OK-ish, but now if you
turn the panel off not only will the touchscreen remain powered, but
the power rails for the panel itself won't be switched off, burning
extra power.
The above two inefficiencies are _extra_ minor when you consider the
fact that laptops rarely spend much time with the screen off. The main
use case would be when an external screen (and presumably a power
supply) is attached.
Unfortunately, it gets worse from here. On sc7180-trogdor-homestar,
for instance, the display's TCON (timing controller) sometimes crashes
if you don't power cycle it whenever you stop and restart the video
stream (like during a modeset). The touchscreen keeping the power
rails on causes real problems. One proposal in the homestar timeframe
was to move the touchscreen to an always-on rail, dedicating the main
power rail to the panel. That caused _different_ problems as talked
about in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the
reset line to the regulator"). The end result of all of this was to
add an extra regulator to the board, increasing cost.
Recently, Cong Yang posted a patch [1] where things are even worse.
The panel and touch controller on that system seem even more
intimately tied together and really can't be thought of separately.
To address this issue, let's start allowing devices to register
themselves as "panel followers". These devices will get called after a
panel has been powered on and before a panel is powered off. This
makes the panel the primary device in charge of the power state, which
matches how userspace uses it.
The panel follower API should be fairly straightforward to use. The
current code assumes that panel followers are using device tree and
have a "panel" property pointing to the panel to follow. More
flexibility and non-DT implementations could be added as needed.
Right now, panel followers can follow the prepare/unprepare functions.
There could be arguments made that, instead, they should follow
enable/disable. I've chosen prepare/unprepare for now since those
functions are guaranteed to power up/power down the panel and it seems
better to start the process earlier.
A bit of explaining about why this is a roll-your-own API instead of
using something more standard:
1. In standard APIs in Linux, parent devices are automatically powered
on when a child needs power. Applying that here, it would mean that
we'd force the panel on any time someone was listening to the
touchscreen. That, unfortunately, would have broken homestar's need
(if we hadn't changed the hardware, as per above) where the panel
absolutely needs to be able to power cycle itself. While one could
argue that homestar is broken hardware and we shouldn't have the
API do backflips for it, _officially_ the eDP timing guidelines
agree with homestar's needs and the panel power sequencing diagrams
show power going off. It's nice to be able to support this.
2. We could, conceibably, try to add a new flag to device_link causing
the parent to be in charge of power. Then we could at least use
normal pm_runtime APIs. This sounds great, except that we run into
problems with initial probe. As talked about in the later patch
("HID: i2c-hid: Support being a panel follower") the initial power
on of a panel follower might need to do things (like add
sub-devices) that aren't allowed in a runtime_resume function.
The above complexities explain why this API isn't using common
functions. That being said, this patch is very small and
self-contained, so if someone was later able to adapt it to using more
common APIs while solving the above issues then that could happen in
the future.
Douglas Anderson [Thu, 27 Jul 2023 17:16:29 +0000 (10:16 -0700)]
drm/panel: Check for already prepared/enabled in drm_panel
In a whole pile of panel drivers, we have code to make the
prepare/unprepare/enable/disable callbacks behave as no-ops if they've
already been called. It's silly to have this code duplicated
everywhere. Add it to the core instead so that we can eventually
delete it from all the drivers. Note: to get some idea of the
duplicated code, try:
git grep 'if.*>prepared' -- drivers/gpu/drm/panel
git grep 'if.*>enabled' -- drivers/gpu/drm/panel
NOTE: arguably, the right thing to do here is actually to skip this
patch and simply remove all the extra checks from the individual
drivers. Perhaps the checks were needed at some point in time in the
past but maybe they no longer are? Certainly as we continue
transitioning over to "panel_bridge" then we expect there to be much
less variety in how these calls are made. When we're called as part of
the bridge chain, things should be pretty simple. In fact, there was
some discussion in the past about these checks [1], including a
discussion about whether the checks were needed and whether the calls
ought to be refcounted. At the time, I decided not to mess with it
because it felt too risky.
Looking closer at it now, I'm fairly certain that nothing in the
existing codebase is expecting these calls to be refcounted. The only
real question is whether someone is already doing something to ensure
prepare()/unprepare() match and enabled()/disable() match. I would say
that, even if there is something else ensuring that things match,
there's enough complexity that adding an extra bool and an extra
double-check here is a good idea. Let's add a drm_warn() to let people
know that it's considered a minor error to take advantage of
drm_panel's double-checking but we'll still make things work fine.
We'll also add an entry to the official DRM todo list to remove the
now pointless check from the panels after this patch lands and,
eventually, fixup anyone who is triggering the new warning.
Douglas Anderson [Thu, 27 Jul 2023 17:16:28 +0000 (10:16 -0700)]
dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed touchscreens
As talked about in the patch ("drm/panel: Add a way for other devices
to follow panel state"), touchscreens that are connected to panels are
generally expected to be power sequenced together with the panel
they're attached to. Today, nothing provides information allowing you
to find out that a touchscreen is connected to a panel. Let's add a
phandle for this.
The proerty is added to the generic touchscreen bindings and then
enabled in the bindings for the i2c-hid backed devices. This can and
should be added for other touchscreens in the future, but for now
let's start small.
A very basic debugging rule when a device is connected for the first
time is to access a read-only register which contains known data in
order to ensure the communication protocol is properly working. This
driver lacked any read helper which is often a critical piece for
speeding-up bring-ups.
Add a read helper and use it to verify the communication with the panel
is working as soon as possible in order to inform the user early if this
is not the case.
As this panel may work with no MISO line, the check is discarded in this
case. Upon error, we do not fail probing but just warn the user, in case
the DT description would be lacking the Rx bus width (which is likely on
old descriptions) in order to avoid breaking existing devices.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Tested-by: Sebastian Reichel <sre@kernel.org> # no MISO line Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-20-sre@kernel.org
drm/panel: sitronix-st7789v: Add EDT ET028013DMA panel support
This panel from Emerging Display Technologies Corporation features an
ST7789V2 LCD controller panel inside which is almost identical to what
the Sitronix panel driver supports.
In practice, the module physical size is specific, and experiments show
that the display will malfunction if any of the following situation
occurs:
* Pixel clock is above 3MHz
* Pixel clock is not inverted
I could not properly identify the reasons behind these failures, scope
captures show valid input signals.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-19-sre@kernel.org
drm/panel: sitronix-st7789v: Use 9 bits per spi word by default
The Sitronix controller expects 9-bit words, provide this as default at
probe time rather than specifying this in each and every access.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Tested-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-17-sre@kernel.org
dt-bindings: display: st7789v: bound the number of Rx data lines
The ST7789V LCD controller supports regular SPI wiring, as well as no Rx
data line at all. The operating system needs to know whether it can read
registers from the device or not. Let's detail this specific design
possibility by bounding the spi-rx-bus-width property.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Tested-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-16-sre@kernel.org
drm/panel: sitronix-st7789v: add Inanbo T28CP45TN89 support
UNI-T UTi260b has a Inanbo T28CP45TN89 v17 panel. I could not find
proper documentation for the panel apart from a technical drawing, but
according to the vendor U-Boot it is based on a Sitronix st7789v chip.
I generated the init sequence by modifying the default one until proper
graphics output has been seen on the device.
drm/panel: sitronix-st7789v: avoid hardcoding polarity info
Add polarity information via mode and bus flags, so that they are no
longer hardcoded and forward the information to the DRM stack. This is
required for adding panels with different settings.
Add support for describing the media bus format in the
panel configuration and expose that to userspace. Since
both supported formats (RGB565 and RGB666) are using 6
bits per color also hardcode that information.
drm/panel: sitronix-st7789v: avoid hardcoding mode info
Avoid hard-coding the default_mode and supply it from match data. One
additional layer of abstraction has been introduced, which will be
needed for specifying other panel information (e.g. bus flags) in the
next steps.
Arthur Grillo [Mon, 31 Jul 2023 18:22:41 +0000 (15:22 -0300)]
drm/tests: Alloc drm_device on drm_exec tests
The drm_exec tests where crashing[0] because of a null dereference. This
is caused by a new access of the `driver` attribute of `struct
drm_driver` on drm_gem_private_object_init(). Alloc the drm_device to
fix that.
drm/i915: Add function to clear scanout flag for vmas
Currently frontbuffer tracking code is directly iterating over object vmas
and clearing scanout flags for them. Add function to clear scanout flag for
vmas and use it from frontbuffer tracking code.
drm/i915/display: Remove i915_gem_object_types.h from intel_frontbuffer.h
Now as we have removed all the references to internals of i915_gem_object
from the frontbuffer header we can also remove including
i915_gem_object_types.h.
drm/i915: Add macros to get i915 device from i915_gem_object
We want to stop touching directly i915_gem_object struct members in
intel_frontbuffer code. As a part of this we add helper macro to get i915
device from i915_gem_object.
v2: operate on and return pointer in defined macros
Dmitry Osipenko [Thu, 23 Mar 2023 23:07:55 +0000 (02:07 +0300)]
drm/virtio: Support sync objects
Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
support is needed by native context VirtIO-GPU Mesa drivers, it also will
be used by Venus and Virgl contexts.
Reviewed-by; Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> # amdgpu nctx Tested-by: Rob Clark <robdclark@gmail.com> # freedreno nctx Reviewed-by: Rob Clark <robdclark@gmail.com> Acked-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230416115237.798604-4-dmitry.osipenko@collabora.com
Deferred-I/O generator macros generate callbacks for struct fb_ops
that operate on memory ranges in I/O address space or system address
space. Rename the macros to use the _IOMEM_ and _SYSMEM_ infixes of
their underlying helpers. Adapt all users. No functional changes.
Change the infix for fbdev's DMA-memory helpers from _DMA_ to
_DMAMEM_. The helpers perform operations within DMA-able memory,
but they don't perform DMA operations. Naming should make this
clear. Adapt all users. No functional changes.
fbdev: Use _SYSMEM_ infix for system-memory helpers
Change the infix for fbdev's system-memory helpers from _SYS_ to
_SYSMEM_. The helpers perform operations within system memory, but
not on the state of the operating system itself. Naming should make
this clear. Adapt all users. No functional changes.
Change the infix for fbdev's I/O-memory helpers from _IO_ to _IOMEM_
to distiguish them from other types of I/O, such as file operations.
The helpers operate on memory ranges in the I/O address space and the
naming should make this clear. Adapt all users. No functional changes.
Marek Vasut [Sun, 9 Jul 2023 13:49:14 +0000 (15:49 +0200)]
drm/panel: simple: Add missing connector type and pixel format for AUO T215HVN01
The connector type and pixel format are missing for this panel,
add them to prevent various drivers from failing to determine
either of those parameters.
The newly added driver only builds when DRM_DISPLAY_DP_HELPER is enabled:
x86_64-linux-ld: drivers/gpu/drm/panel/panel-visionox-r66451.o: in function `visionox_r66451_enable':
panel-visionox-r66451.c:(.text+0x105): undefined reference to `drm_dsc_pps_payload_pack'
Select both CONFIG_DRM_DISPLAY_DP_HELPER and CONFIG_DRM_DISPLAY_HELPER to
ensure the helper function is always available.
Maxime Ripard [Fri, 28 Jul 2023 09:06:24 +0000 (11:06 +0200)]
drm/vc4: tests: pv-muxing: Document test scenario
We've had a couple of tests that weren't really obvious, nor did they
document what they were supposed to test. Document that to make it
hopefully more obvious.
Maxime Ripard [Fri, 28 Jul 2023 09:06:20 +0000 (11:06 +0200)]
drm/vc4: tests: pv-muxing: Remove call to drm_kunit_helper_free_device()
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
Maxime Ripard [Fri, 28 Jul 2023 09:06:19 +0000 (11:06 +0200)]
drm/tests: helpers: Create a helper to allocate an atomic state
As we gain more tests, boilerplate to allocate an atomic state and free
it starts to be there more and more as well.
In order to reduce the allocation boilerplate, we can create a helper
to create that atomic state, and call an action when the test is done.
This will also clean up the exit path.
Maxime Ripard [Fri, 28 Jul 2023 09:06:17 +0000 (11:06 +0200)]
drm/tests: probe-helper: Remove call to drm_kunit_helper_free_device()
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
Maxime Ripard [Fri, 28 Jul 2023 09:06:16 +0000 (11:06 +0200)]
drm/tests: modes: Remove call to drm_kunit_helper_free_device()
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
projects / mirror_ubuntu-kernels.git / log