Neil Armstrong [Tue, 30 May 2023 07:38:13 +0000 (09:38 +0200)]
drm/meson: add support for MIPI-DSI transceiver
The Amlogic G12A/G12B/SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver
(ver 1.21a), with a custom glue managing the IP resets, clock and data
inputs similar to the DW-HDMI Glue on other Amlogic SoCs.
This adds support for the Glue managing the transceiver, mimicing the init
flow provided by Amlogic to setup the ENCL encoder, the glue, the transceiver,
the digital D-PHY and the Analog PHY in the proper way.
An optional "MEAS" clock can be enabled to measure the delay between each
vsync feeding the DW-MIPI-DSI transceiver.
Neil Armstrong [Tue, 30 May 2023 07:38:12 +0000 (09:38 +0200)]
drm/meson: add DSI encoder
This adds an encoder bridge designed to drive a MIPI-DSI display
by using the ENCL encoder through the internal MIPI DSI transceiver
connected to the output of the ENCL pixel encoder.
Neil Armstrong [Tue, 30 May 2023 07:38:10 +0000 (09:38 +0200)]
drm/meson: only use components with dw-hdmi
Only DW-HDMI currently needs components since it reuses
the drm-meson driver context to access HHI registers (sic).
Once this is solved, we can get rid on components.
Until now, limit the components matching to the dw-hdmi compatibles
we know to require this hack, for other bridges simply use probe defer
instead and get over this components sitation.
The back story is that we simply cannot attach DSI adapters bridges
if we use components, only DSI panels, this is because we bind/unbind
the DSI controller at each drm-meson driver master bind tentative.
With this the I2C DSI bridge is unable to find the DSI controller
host and everything fails to probe.
This will simplify a lot adding new or older HDMI bridges.
Neil Armstrong [Tue, 30 May 2023 07:38:09 +0000 (09:38 +0200)]
drm/meson: fix unbind path if HDMI fails to bind
If the case the HDMI controller fails to bind, we try to unbind
all components before calling drm_dev_put() which makes drm_bridge_detach()
crash because unbinding the HDMI controller frees the bridge memory.
The solution is the unbind all components at the end like in the remove
path.
The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI
transceiver (ver 1.21a) with a custom glue managing the IP resets,
clock and data inputs similar to the DW-HDMI Glue on the same
Amlogic SoC families.
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.
i915's fbdev emulation is still incomplete as it doesn't implement
deferred I/O and damage handling for mmaped pages.
v4:
* generate deferred-I/O helpers
* use initializer macros for fb_ops
v2:
* use FB_IO_HELPERS options
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
* use initializer macros for fb_ops
v2:
* use FB_SYS_HELPERS_DEFERRED option
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Msm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
Msm's fbdev emulation has been incomplete as it didn't implement
damage handling. Partilly fix this by implementing damage handling
for write and draw operation. It is still missing for mmaped pages.
v4:
* use initializer macros for struct fb_ops
* partially support damage handling
v2:
* use FB_SYS_HELPERS option
drm/fb-helper: Export helpers for marking damage areas
Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
handle damage areas for fbdev emulation. This is a temporary export
that allows to move the DRM I/O helpers for fbdev into drivers. Only
fbdev-generic and i915 need them. Both will be updated to implement
damage handling by themselves and the exported functions will be removed.
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Tegra does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_SYS_HELPERS option
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Omapdrm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_SYS_HELPERS option
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Fbdev-dma does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_SYS_HELPERS option
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Radeon does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_IO_HELPERS option
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Gma500 does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_IO_HELPERS option
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v3:
* don't reorder Makefile rules (Sam)
v2:
* use FB_IO_HELPERS option
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_IO_HELPERS option
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.
These macros can remove a lot boilerplate code from fbdev drivers.
The drivers are supposed to use the macro that is required for its
framebuffer. Each macro is split into smaller helpers, so that
drivers with non-standard callbacks can pick and customize callbacks
as needed. There are individual helper macros for read/write, mmap
and drawing.
fbdev: Add Kconfig options to select different fb_ops helpers
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver configs.
Fabio Estevam [Wed, 31 May 2023 22:44:07 +0000 (19:44 -0300)]
dt-bindings: samsung,mipi-dsim: Use port-base reference
Use port-base reference for port@1.
This fixes the following schema warning:
imx8mp-dhcom-pdk3.dtb: dsi@32e60000: ports:port@1:endpoint: Unevaluated properties are not allowed ('data-lanes' was unexpected)
From schema: Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
Ashutosh Dixit [Wed, 24 May 2023 21:56:29 +0000 (14:56 -0700)]
drm/i915/pmu: Make PMU sample array two-dimensional
No functional changes but we can remove some unsightly index computation
and read/write functions if we convert the PMU sample array from a
one-dimensional to a two-dimensional array.
Ashutosh Dixit [Wed, 24 May 2023 21:56:28 +0000 (14:56 -0700)]
drm/i915/pmu: Turn off the timer to sample frequencies when GT is parked
pmu_needs_timer() keeps the timer running even when GT is parked,
ostensibly to sample requested/actual frequencies. However
frequency_sample() has the following:
/* Report 0/0 (actual/requested) frequency while parked. */
if (!intel_gt_pm_get_if_awake(gt))
return;
The above code prevents frequencies to be sampled while the GT is
parked. So we might as well turn off the sampling timer itself in this
case and save CPU cycles/power.
v2: Instead of turning freq bits off, return false, since no counters will
run after this change when GT is parked (Tvrtko)
v3: Remove gpu_active argument of pmu_needs_timer (Andrzej)
Ashutosh Dixit [Tue, 23 May 2023 20:40:42 +0000 (13:40 -0700)]
drm/i915/perf: Clear out entire reports after reading if not power of 2 size
Clearing out report id and timestamp as means to detect unlanded reports
only works if report size is power of 2. That is, only when report size is
a sub-multiple of the OA buffer size can we be certain that reports will
land at the same place each time in the OA buffer (after rewind). If report
size is not a power of 2, we need to zero out the entire report to be able
to detect unlanded reports reliably.
Jani Nikula [Thu, 25 May 2023 21:06:53 +0000 (00:06 +0300)]
drm/i915: use localized __diag_ignore_all() instead of per file
Use localized __diag_push(), __diag_ignore_all() with rationale, and
__diag_pop() for specific initializations instead of blanket disabling
of -Woverride-init across several files.
On some devices the +5V Power pin of the HDMI connector and/or the ESD
protection logic is powered on by a separate regulator. Instead of
declaring this regulator as always-on, make hdmi-connector support the
additional hdmi-pwr supply.
Follow the dp-connector example and add hdmi-pwr supply to drive the 5V
pin of the HDMI connector (together with some simple glue logic possibly
attached to the connector).
Suraj Kandpal [Mon, 29 May 2023 11:07:40 +0000 (16:37 +0530)]
drm/i915/hdcp: Rename comp_mutex to hdcp_mutex
Rename comp_mutex to hdcp_mutex as it does not just
protect component related variables which was a terminology
used when hdcp was to be binded as a mei component from MTL
we use gsc cs which does not use the component binding path
for HDCP.
Suraj Kandpal [Mon, 29 May 2023 11:07:39 +0000 (16:37 +0530)]
drm/i915/hdcp: Move away from master naming to arbiter
Rename variables to move away from master convention to
arbiter
%s/hdcp.master/hdcp.arbiter
%s/i915_hdcp_master/i915_hdcp_arbiter
%s/comp_master/comp_arbiter
--v2
- delete i915_hdcp_comp_master redundant declaration [Chaitanya]
- use %s/foo/bar/ format in commit message to show changes [Chaitanya]
--v3
- replace i915_hdcp_comp_master declaration with i915_hdcp_arbiter
to avoid any compile fail with old compilers [Chaitanya]
Uwe Kleine-König [Tue, 30 May 2023 07:42:16 +0000 (09:42 +0200)]
drm/panel-edp: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
panel_edp_remove() always returned zero, so convert it to return void
without any loss and then just drop the return from
panel_edp_platform_remove().
Uwe Kleine-König [Fri, 26 May 2023 09:07:09 +0000 (11:07 +0200)]
drm: Switch i2c drivers back to use .probe()
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.
Michal Wajdeczko [Fri, 26 May 2023 23:55:38 +0000 (16:55 -0700)]
drm/i915/guc: Track all sent actions to GuC
For easier debug of any unexpected error responses from GuC that
might be related to non-blocking fast requests, track action code (and
stack if under DEBUG_GUC config) for every H2G request.
Michal Wajdeczko [Fri, 26 May 2023 23:55:36 +0000 (16:55 -0700)]
drm/i915/guc: Use FAST_REQUEST for non-blocking H2G calls
In addition to the already defined REQUEST HXG message format,
which is used when sender expects some confirmation or data,
HXG protocol includes definition of the FAST REQUEST message,
that may be used when sender does not expect any useful data
to be returned.
Using this instead of GUC_HXG_TYPE_EVENT for non-blocking CTB requests
will allow GuC to send back GUC_HXG_TYPE_RESPONSE_FAILURE in case of
errors.
Note that it is not possible to return such errors to the caller,
since this is for non-blocking calls and the related fence is not
stored. Instead such messages are treated as unexpected, which will
give an indication of potential GuC misprogramming that warrants extra
debugging effort.
Chris Wilson [Wed, 17 May 2023 13:57:54 +0000 (19:27 +0530)]
drm/i915/gem: Use large rings for compute contexts
Allow compute contexts to submit the maximal amount of work without
blocking userspace.
The original size for user LRC ring's (SZ_16K) was chosen to minimise
memory consumption, without being so small as to frequently stall in the
middle of workloads. With the main consumers being GL / media pipelines
of 2 or 3 batches per frame, we want to support ~10 requests in flight
to allow for the application to control throttling without stalling
within a frame.
Adam Ford [Sun, 28 May 2023 13:27:27 +0000 (08:27 -0500)]
dt-bindings: bridge: samsung-dsim: Make some flags optional
In the event a device is connected to the samsung-dsim
controller that doesn't support the burst-clock, the
driver is able to get the requested pixel clock from the
attached device or bridge. In these instances, the
samsung,burst-clock-frequency isn't needed, so remove
it from the required list.
The pll-clock frequency can be set by the device tree entry
for samsung,pll-clock-frequency, but in some cases, the
pll-clock may have the same clock rate as sclk_mipi clock.
If they are equal, this flag is not needed since the driver
will use the sclk_mipi rate as a fallback.
Wolfram Sang [Tue, 9 May 2023 07:48:17 +0000 (09:48 +0200)]
drm: rcar-du: remove R-Car H3 ES1.* workarounds
R-Car H3 ES1.* was only available to an internal development group and
needed a lot of quirks and workarounds. These become a maintenance
burden now, so our development group decided to remove upstream support
for this SoC and prevent booting it. Public users only have ES2 onwards.
Dave Airlie [Sun, 28 May 2023 20:21:50 +0000 (06:21 +1000)]
Merge tag 'drm-intel-gt-next-2023-05-24' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
UAPI Changes:
- New getparam for querying PXP support and load status
Cross-subsystem Changes:
- GSC/MEI proxy driver
Driver Changes:
Fixes/improvements/new stuff:
- Avoid clearing pre-allocated framebuffers with the TTM backend (Nirmoy Das)
- Implement framebuffer mmap support (Nirmoy Das)
- Disable sampler indirect state in bindless heap (Lionel Landwerlin)
- Avoid out-of-bounds access when loading HuC (Lucas De Marchi)
- Actually return an error if GuC version range check fails (John Harrison)
- Get mutex and rpm ref just once in hwm_power_max_write (Ashutosh Dixit)
- Disable PL1 power limit when loading GuC firmware (Ashutosh Dixit)
- Block in hwmon while waiting for GuC reset to complete (Ashutosh Dixit)
- Provide sysfs for SLPC efficient freq (Vinay Belgaumkar)
- Add support for total context runtime for GuC back-end (Umesh Nerlige Ramappa)
- Enable fdinfo for GuC backends (Umesh Nerlige Ramappa)
- Don't capture Gen8 regs on Xe devices (John Harrison)
- Fix error capture for virtual engines (John Harrison)
- Track patch level versions on reduced version firmware files (John Harrison)
- Decode another GuC load failure case (John Harrison)
- GuC loading and firmware table handling fixes (John Harrison)
- Fix confused register capture list creation (John Harrison)
- Dump error capture to kernel log (John Harrison)
- Dump error capture to dmesg on CTB error (John Harrison)
- Disable rps_boost debugfs when SLPC is used (Vinay Belgaumkar)
Future platform enablement:
- Disable stolen memory backed FB for A0 [mtl] (Nirmoy Das)
- Various refactors for multi-tile enablement (Andi Shyti, Tejas Upadhyay)
- Extend Wa_22011802037 to MTL A-step (Madhumitha Tolakanahalli Pradeep)
- WA to clear RDOP clock gating [mtl] (Haridhar Kalvala)
- Set has_llc=0 [mtl] (Fei Yang)
- Define MOCS and PAT tables for MTL (Madhumitha Tolakanahalli Pradeep)
- Add PTE encode function [mtl] (Fei Yang)
- fix mocs selftest [mtl] (Fei Yang)
- Workaround coherency issue for Media [mtl] (Fei Yang)
- Add workaround 14018778641 [mtl] (Tejas Upadhyay)
- Implement Wa_14019141245 [mtl] (Radhakrishna Sripada)
- Fix the wa number for Wa_22016670082 [mtl] (Radhakrishna Sripada)
- Use correct huge page manager for MTL (Jonathan Cavitt)
- GSC/MEI support for Meteorlake (Alexander Usyskin, Daniele Ceraolo Spurio)
- Define GuC firmware version for MTL (John Harrison)
- Drop FLAT CCS check [mtl] (Pallavi Mishra)
- Add MTL for remapping CCS FBs [mtl] (Clint Taylor)
- Meteorlake PXP enablement (Alan Previn)
- Do not enable render power-gating on MTL (Andrzej Hajda)
- Add MTL performance tuning changes (Radhakrishna Sripada)
- Extend Wa_16014892111 to MTL A-step (Radhakrishna Sripada)
- PMU multi-tile support (Tvrtko Ursulin)
- End support for set caching ioctl [mtl] (Fei Yang)
Driver refactors:
- Use i915 instead of dev_priv insied the file_priv structure (Andi Shyti)
- Use proper parameter naming in for_each_engine() (Andi Shyti)
- Use gt_err for GT info (Tejas Upadhyay)
- Consolidate duplicated capture list code (John Harrison)
- Capture list naming clean up (John Harrison)
- Use kernel-doc -Werror when CONFIG_DRM_I915_WERROR=y (Jani Nikula)
- Preparation for using PAT index (Fei Yang)
- Use pat_index instead of cache_level (Fei Yang)
Miscellaneous:
- Fix memory leaks in i915 selftests (Cong Liu)
- Record GT error for gt failure (Tejas Upadhyay)
- Migrate platform-dependent mock hugepage selftests to live (Jonathan Cavitt)
- Update the SLPC selftest (Vinay Belgaumkar)
- Throw out set() wrapper (Jani Nikula)
- Large driver kernel doc cleanup (Jani Nikula)
- Fix probe injection CI failures after recent change (John Harrison)
- Make unexpected firmware versions an error in debug builds (John Harrison)
- Silence UBSAN uninitialized bool variable warning (Ashutosh Dixit)
- Fix memory leaks in function live_nop_switch (Cong Liu)
Merges:
- Merge drm/drm-next into drm-intel-gt-next (Joonas Lahtinen)
Liu Ying [Wed, 10 May 2023 09:24:50 +0000 (17:24 +0800)]
drm: lcdif: Add i.MX93 LCDIF compatible string
With all previous preparations done to make it possible for the
single LCDIF embedded in i.MX93 SoC to drive multiple displays
simultaneously, add i.MX93 LCDIF compatible string as the last
step of adding i.MX93 LCDIF support.
Liu Ying [Wed, 10 May 2023 09:24:49 +0000 (17:24 +0800)]
drm: lcdif: Add multiple encoders and first bridges support
The single LCDIF embedded in i.MX93 SoC may drive multiple displays
simultaneously. Look at LCDIF output port's remote port parents to
find all enabled first bridges. Add an encoder for each found bridge
and attach the bridge to the encoder. This is a preparation for
adding i.MX93 LCDIF support.
Liu Ying [Wed, 10 May 2023 09:24:48 +0000 (17:24 +0800)]
drm: lcdif: Check consistent bus format and flags across first bridges
The single LCDIF embedded in i.MX93 SoC may drive multiple displays
simultaneously. Check bus format and flags across first bridges in
->atomic_check() to ensure they are consistent. This is a preparation
for adding i.MX93 LCDIF support.
Liu Ying [Wed, 10 May 2023 09:24:47 +0000 (17:24 +0800)]
drm: lcdif: Determine bus format and flags in ->atomic_check()
Instead of determining LCDIF output bus format and bus flags in
->atomic_enable(), do that in ->atomic_check(). This is a
preparation for the upcoming patch to check consistent bus format
and bus flags across all first downstream bridges in ->atomic_check().
New lcdif_crtc_state structure is introduced to cache bus format
and bus flags states in ->atomic_check() so that they can be read
in ->atomic_enable().
Liu Ying [Wed, 10 May 2023 09:24:46 +0000 (17:24 +0800)]
drm: lcdif: Drop unnecessary NULL pointer check on lcdif->bridge
A valid bridge is already found in lcdif_attach_bridge() and set
to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop
the unnecessary NULL pointer check in KMS stage.
Liu Ying [Wed, 10 May 2023 09:24:45 +0000 (17:24 +0800)]
dt-bindings: lcdif: Add i.MX93 LCDIF support
There is one LCDIF embedded in i.MX93 SoC to connect with
MIPI DSI controller through LCDIF cross line pattern(controlled
by mediamix blk-ctrl) or connect with LVDS display bridge(LDB)
directly or connect with a parallel display through parallel
display format(also controlled by mediamix blk-ctrl). i.MX93
LCDIF IP is essentially the same to i.MX8MP LCDIF IP. Add device
tree binding for i.MX93 LCDIF.
Ville Syrjälä [Thu, 13 Apr 2023 16:49:14 +0000 (19:49 +0300)]
drm/i915: Implement CTM property support for VLV
VLV has a so called "wide gamut color correction" unit (WGC).
What it is is a 3x3 matrix similar to the later CHV CGM
CSC, with less precisions/range. In fact CHV also has the WGC
but using it there doesn't really make sense when you have the
superior CGM CSC around.
Hook up the necessary stuff to expose the WGC as the CTM
crtc property.
One additional crazy idea that came to mind would be to use
the WGC as an output CSC on CHV for YCbCr output. But it
would be incompatible with the legacy LUT usage. In fact
since the WGC lacks post-offsets we'd probably have to
use the legacy LUT to do that final part of the RGB->YCbCr
conversion. Sounds doable, but perhaps not worth the hassle.
Ville Syrjälä [Thu, 13 Apr 2023 16:49:13 +0000 (19:49 +0300)]
drm/i915: Always enable CGM CSC on CHV
On CHV toggling the CGM CSC on/off while the pipe is running leads
to underruns. Looks like we'd have to do the toggling strictly inside
the start_of_vblank-frame_start window to avoid this, but that window
is less than a scanline so there's no way we can guarantee hitting it.
As a workaround let's just leave the CGM CSC permanently enabled.
Fortunately the CGM gamma/degamma units don't seem to suffer from
this malady.
I also tried turning off CGM unit clock gating, but that did not
help.
The CHV CGM CSC coefficients are in s4.12 two's complement
format. Fix the CTM->CGM conversion to handle that correctly
instead of pretending that the hw coefficients are also
in some sign-magnitude format.
Ville Syrjälä [Thu, 13 Apr 2023 16:49:11 +0000 (19:49 +0300)]
drm/i915: Expose crtc CTM property on ilk/snb
The ilk/snb code is internally fully capable of handling the
CTM property, so expose it.
Note that we still choose not to expose DEGAMMA_LUT though.
The hardware is capable if degamma or gamma, but not both
simultanously due to lack of the split gamma mode. Exposing
both LUTs might encourage userspace to try enabling both
at the same time.
Yang Li [Fri, 21 Apr 2023 08:34:02 +0000 (16:34 +0800)]
drm/stm: dsi: Use devm_platform_ioremap_resource()
Convert platform_get_resource(),devm_ioremap_resource() to a single call
to devm_platform_ioremap_resource(), as this is exactly what this function
does.
drm/i915: Fix clang -Wimplicit-fallthrough in intel_async_flip_check_hw()
Clang warns:
drivers/gpu/drm/i915/display/intel_display.c:6012:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case I915_FORMAT_MOD_X_TILED:
^
drivers/gpu/drm/i915/display/intel_display.c:6012:3: note: insert 'break;' to avoid fall-through
case I915_FORMAT_MOD_X_TILED:
^
break;
1 error generated.
Clang is a little more pedantic than GCC, which does not warn when
falling through to a case that is just break or return. Clang's version
is more in line with the kernel's own stance in deprecated.rst, which
states that all switch/case blocks must end in either break,
fallthrough, continue, goto, or return. Add the missing break to silence
the warning.
Dario Binacchi [Tue, 16 May 2023 08:50:39 +0000 (10:50 +0200)]
drm/panel: simple: fix active size for Ampire AM-480272H3TMQW-T01H
The previous setting was related to the overall dimension and not to the
active display area.
In the "PHYSICAL SPECIFICATIONS" section, the datasheet shows the
following parameters:
----------------------------------------------------------
| Item | Specifications | unit |
----------------------------------------------------------
| Display area | 98.7 (W) x 57.5 (H) | mm |
----------------------------------------------------------
| Overall dimension | 105.5(W) x 67.2(H) x 4.96(D) | mm |
----------------------------------------------------------
Adam Ford [Fri, 26 May 2023 03:05:59 +0000 (22:05 -0500)]
dt-bindings: bridge: samsung-dsim: Make some flags optional
In the event a device is connected to the samsung-dsim
controller that doesn't support the burst-clock, the
driver is able to get the requested pixel clock from the
attached device or bridge. In these instances, the
samsung,burst-clock-frequency isn't needed, so remove
it from the required list.
The pll-clock frequency can be set by the device tree entry
for samsung,pll-clock-frequency, but in some cases, the
pll-clock may have the same clock rate as sclk_mipi clock.
If they are equal, this flag is not needed since the driver
will use the sclk_mipi rate as a fallback.
Adam Ford [Fri, 26 May 2023 03:05:58 +0000 (22:05 -0500)]
drm: bridge: samsung-dsim: Support non-burst mode
The high-speed clock is hard-coded to the burst-clock
frequency specified in the device tree. However, when
using devices like certain bridge chips without burst mode
and varying resolutions and refresh rates, it may be
necessary to set the high-speed clock dynamically based
on the desired pixel clock for the connected device.
This also removes the need to set a clock speed from
the device tree for non-burst mode operation, since the
pixel clock rate is the rate requested from the attached
device like a bridge chip. This should have no impact
for people using burst-mode and setting the burst clock
rate is still required for those users. If the burst
clock is not present, change the error message to
dev_info indicating the clock use the pixel clock.
The DPHY timings are currently hard coded. Since the input
clock can be variable, the phy timings need to be variable
too. To facilitate this, we need to cache the hs_clock
based on what is generated from the PLL.
The phy_mipi_dphy_get_default_config_for_hsclk function
configures the DPHY timings in pico-seconds, and a small macro
converts those timings into clock cycles based on the hs_clk.
In order to support variable DPHY timings, it's necessary
to enable GENERIC_PHY_MIPI_DPHY so phy_mipi_dphy_get_default_config
can be used to determine the nominal values for a given resolution
and refresh rate.
Make the pll-clock-frequency optional. If it's present, use it
to maintain backwards compatibility with existing hardware. If it
is absent, read clock rate of "sclk_mipi" to determine the rate.
Since it can be optional, change the message from an error to
dev_info.
Adam Ford [Fri, 26 May 2023 03:05:54 +0000 (22:05 -0500)]
drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp]
According to Table 13-45 of the i.MX8M Mini Reference Manual, the min
and max values for M and the frequency range for the VCO_out
calculator were incorrect. This information was contradicted in other
parts of the mini, nano and plus manuals. After reaching out to my
NXP Rep, when confronting him about discrepencies in the Nano manual,
he responded with:
"Yes it is definitely wrong, the one that is part
of the NOTE in MIPI_DPHY_M_PLLPMS register table against PMS_P,
PMS_M and PMS_S is not correct. I will report this to Doc team,
the one customer should be take into account is the Table 13-40
DPHY PLL Parameters and the Note above."
These updated values also match what is used in the NXP downstream
kernel.
To fix this, make new variables to hold the min and max values of m
and the minimum value of VCO_out, and update the PMS calculator to
use these new variables instead of using hard-coded values to keep
the backwards compatibility with other parts using this driver.
Scale the blanking packet sizes to match the ratio between HS clock
and DPI interface clock. The controller seems to do internal scaling
to the number of active lanes, so we don't take those into account.
drm/bridge: ti-sn65dsi83: Fix enable/disable flow to meet spec
The datasheet describes the following initialization flow including
minimum delay times between each step:
1. DSI data lanes need to be in LP-11 and the clock lane in HS mode
2. toggle EN signal
3. initialize registers
4. enable PLL
5. soft reset
6. enable DSI stream
7. check error status register
To meet this requirement we need to make sure the host bridge's
pre_enable() is called first by using the pre_enable_prev_first
flag.
Furthermore we need to split enable() into pre_enable() which covers
steps 2-5 from above and enable() which covers step 7 and is called
after the host bridge's enable().
drm: bridge: samsung-dsim: Fix i.MX8M enable flow to meet spec
According to the documentation [1] the proper enable flow is:
1. Enable DSI link and keep data lanes in LP-11 (stop state)
2. Disable stop state to bring data lanes into HS mode
Currently we do this all at once within enable(), which doesn't
allow to meet the requirements of some downstream bridges.
To fix this we now enable the DSI in pre_enable() and force it
into stop state using the FORCE_STOP_STATE bit in the ESCMODE
register until enable() is called where we reset the bit.
We currently do this only for i.MX8M as Exynos uses a different
init flow where samsung_dsim_init() is called from
samsung_dsim_host_transfer().
Matt Roper [Tue, 23 May 2023 19:56:08 +0000 (12:56 -0700)]
drm/i915/display: Handle GMD_ID identification in display code
For platforms with GMD_ID support (i.e., everything MTL and beyond),
identification of the display IP present should be based on the contents
of the GMD_ID register rather than a PCI devid match.
Note that since GMD_ID readout requires access to the PCI BAR, a slight
change to the driver init sequence is needed --- pci_enable_device() is
now called before i915_driver_create().
v2:
- Fix use of uninitialized i915 pointer in error path if
pci_enable_device() fails before the i915 device is created. (lkp)
- Use drm_device parameter to intel_display_device_probe. This goes
against i915 conventions, but since the primary goal here is to make
it easy to call this function from other drivers (like Xe) and since
we don't need anything from the i915 structure, this seems like an
exception where drm_device is a more natural fit.
v3:
- Go back do drm_i915_private for intel_display_device_probe. (Jani)
- Move forward decl to top of header. (Jani)
Matt Roper [Tue, 23 May 2023 19:56:07 +0000 (12:56 -0700)]
drm/i915/display: Make display responsible for probing its own IP
Rather than selecting the display IP and feature flags at the same time
the general PCI probing happens, move this step into the display code
itself so that it can be more easily re-used outside of i915 (i.e., by
the Xe driver).
v2:
- Make intel_display_device_probe() always return a non-NULL pointer
and simplify copying of runtime_defaults. (Andrzej)
v3:
- Redefine INTEL_VGA_DEVICE/INTEL_QUANTA_DEVICE to eliminate a cast and
an include of linux/mod_devicetable.h. (Jani)
- Keep explicit memcpy for runtime defaults. (Jani)
Matt Roper [Tue, 23 May 2023 19:56:06 +0000 (12:56 -0700)]
drm/i915/display: Move display runtime info to display structure
Move the runtime info specific to display into display-specific
structures as has already been done with the constant display info.
v2:
- Rename __runtime to __runtime_defaults for more clarity on the
purpose. (Andrzej)
- Move introduction of DISPLAY_INFO() to previous patch. (Andrzej)
- Drop NO_DISPLAY macro. (Andrzej)
v3:
- Use "{}" instead of "{ 0 }" for empty struct init. (Jani)
Rob Clark [Wed, 24 May 2023 15:59:35 +0000 (08:59 -0700)]
drm: Add fdinfo memory stats
Add support to dump GEM stats to fdinfo.
v2: Fix typos, change size units to match docs, use div_u64
v3: Do it in core
v4: more kerneldoc
v5: doc fixes
v6: Actually use u64, bit more comment docs
Rob Clark [Wed, 24 May 2023 15:59:32 +0000 (08:59 -0700)]
drm: Add common fdinfo helper
Handle a bit of the boiler-plate in a single case, and make it easier to
add some core tracked stats. This also ensures consistent behavior
across drivers for standardised fields.
v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo
v3: Rebase on drm-misc-next
Matt Roper [Tue, 23 May 2023 19:56:05 +0000 (12:56 -0700)]
drm/i915: Convert INTEL_INFO()->display to a pointer
Rather than embeddeding the display's device info within the main device
info structure, just provide a pointer to the display-specific
structure. This is in preparation for moving the display device info
definitions into the display code itself and for eventually allowing the
pointer to be assigned at runtime on platforms that use GMD_ID for
device identification.
In the future, this will also eventually allow the same display device
info structures to be used outside the current i915 code (e.g., from the
Xe driver).
v2:
- Move introduction of DISPLAY_INFO() to this patch. (Andrzej)
v3:
- Also use DISPLAY_INFO() in intel_display_reg_defs.h. (Andrzej)
- Use "{}" instead of "{ 0 }" for empty struct init. (Jani)
Matt Roper [Tue, 23 May 2023 19:56:04 +0000 (12:56 -0700)]
drm/i915/display: Move display device info to header under display/
Moving display-specific substructure definitions will help keep display
more self-contained and make it easier to re-use in other drivers (i.e.,
Xe) in the future.
Azeem Shaikh [Mon, 22 May 2023 15:52:28 +0000 (15:52 +0000)]
drm/i915: Replace all non-returning strlcpy with strscpy
strlcpy() reads the entire source buffer first.
This read may exceed the destination size limit.
This is both inefficient and can lead to linear read
overflows if a source string is not NUL-terminated [1].
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with strscpy().
No return values were used, so direct replacement is safe.
drm: shmobile: Make DRM_SHMOBILE visible on Renesas SoC platforms
The LCD Controller supported by the drm-shmob driver is present
on SuperH SH-Mobile SoCs, and on Renesas ARM SH/R-Mobile SoCs.
Unfortunately its config option is not visible on either, so the user
can never enable the support.
Fix this by dropping the dependency on ARM (for SuperH), and by widening
the dependency range to ARCH_RENESAS (for ARM).
drm: shmobile: Switch to drm_crtc_init_with_planes()
The SH-Mobile DRM driver uses the legacy drm_crtc_init(), which
advertizes only the formats in safe_modeset_formats[] (XR24 and AR24) as
being supported.
Switch to drm_crtc_init_with_planes(), and advertize all supported
(A)RGB modes, so we can use RGB565 as the default mode for the console.
Azeem Shaikh [Tue, 23 May 2023 02:19:43 +0000 (02:19 +0000)]
dma-buf/sw_sync: Replace all non-returning strlcpy with strscpy
strlcpy() reads the entire source buffer first.
This read may exceed the destination size limit.
This is both inefficient and can lead to linear read
overflows if a source string is not NUL-terminated [1].
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with strscpy().
No return values were used, so direct replacement is safe.
Artur Weber [Wed, 24 May 2023 08:43:24 +0000 (10:43 +0200)]
drm/panel: samsung-s6d7aa0: use pointer for drm_mode in panel desc struct
Fixes compilation issues with older GCC versions and Clang after
changes introduced in commit 6810bb390282 ("drm/panel: Add Samsung
S6D7AA0 panel controller driver"). Tested with GCC 13.1.1, GCC 6.4.0
and Clang 16.0.3.
Fixes the following errors with Clang:
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:312:14: error: initializer element is not a compile-time constant
.drm_mode = s6d7aa0_lsl080al02_mode,
^~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:415:14: error: initializer element is not a compile-time constant
.drm_mode = s6d7aa0_lsl080al03_mode,
^~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:443:14: error: initializer element is not a compile-time constant
.drm_mode = s6d7aa0_ltl101at01_mode,
^~~~~~~~~~~~~~~~~~~~~~~
3 errors generated.
Fixes the following errors with GCC:
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:312:14: error: initializer element is not constant
.drm_mode = s6d7aa0_lsl080al02_mode,
^~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:312:14: note: (near initialization for 's6d7aa0_lsl080al02_desc.drm_mode')
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:415:14: error: initializer element is not constant
.drm_mode = s6d7aa0_lsl080al03_mode,
^~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:415:14: note: (near initialization for 's6d7aa0_lsl080al03_desc.drm_mode')
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:443:14: error: initializer element is not constant
.drm_mode = s6d7aa0_ltl101at01_mode,
^~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:443:14: note: (near initialization for 's6d7aa0_ltl101at01_desc.drm_mode')
Nirmoy Das [Mon, 22 May 2023 12:42:05 +0000 (14:42 +0200)]
drm/i915: Wait for active retire before i915_active_fini()
i915_active_fini() finalizes the debug object, which can occur before
the active retires and deactivates the debug object. Wait for one
final time before calling i915_active_fini();
Azeem Shaikh [Mon, 22 May 2023 15:52:10 +0000 (15:52 +0000)]
drm/bridge: dw-hdmi: Replace all non-returning strlcpy with strscpy
strlcpy() reads the entire source buffer first.
This read may exceed the destination size limit.
This is both inefficient and can lead to linear read
overflows if a source string is not NUL-terminated [1].
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with strscpy().
No return values were used, so direct replacement is safe.