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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413164916.4221-6-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413164916.4221-5-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
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)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-6-matthew.d.roper@intel.com
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)
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-5-matthew.d.roper@intel.com
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)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-3-matthew.d.roper@intel.com
Fixes compilation issues with older GCC versions and Clang after
changes introduced in commit 6810bb3902 ("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')
Reported-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/lkml/20230523180212.GA1401867@dev-arch.thelio-3990X
Reported-by: kernelci.org bot <bot@kernelci.org>
Link: https://lore.kernel.org/llvm/646c6def.a70a0220.58c1a.903d@mx.google.com
Fixes: 6810bb3902 ("drm/panel: Add Samsung S6D7AA0 panel controller driver")
Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230524084324.11840-1-aweber.kernel@gmail.com
During probe, the driver registers i2c dummy devices and populates the
aux bus, which registers a device for the panel. After doing that, the
driver can still defer probe if needed. This ordering of operations is
troublesome however, because the deferred probe work will retry probing
all pending devices every time a new device is registered. Therefore, if
modules need to be loaded in order to satisfy the dependencies for this
driver to complete probe, the kernel will stall, since it'll keep trying
to probe the anx7625 driver, but never succeed, given that modules would
only be loaded after the deferred probe work completes.
Two changes are required to avoid this issue:
* Move of_find_mipi_dsi_host_by_node(), which can defer probe, to before
anx7625_register_i2c_dummy_clients() and
devm_of_dp_aux_populate_ep_devices(), which register devices.
* Make use of the done_probing callback when populating the aux bus,
so that the bridge registration is only done after the panel is
probed. This is required because the panel might need to defer probe,
but the aux bus population needs the i2c dummy devices working, so
this call couldn't just be moved to an earlier point in probe.
One caveat is that if the panel is described outside the aux bus, the
probe loop issue can still happen, but we don't have a way to avoid
it in that case since there's no callback available.
With this patch applied, it's possible to boot on
mt8192-asurada-spherion with
CONFIG_DRM_ANALOGIX_ANX7625=y
CONFIG_MTK_MMSYS=m
CONFIG_BACKLIGHT_PWM=y
and also with
CONFIG_DRM_ANALOGIX_ANX7625=y
CONFIG_MTK_MMSYS=y
CONFIG_BACKLIGHT_PWM=m
Fixes: adca62ec37 ("drm/bridge: anx7625: Support reading edid through aux channel")
Fixes: 269332997a ("drm/bridge: anx7625: Return -EPROBE_DEFER if the dsi host was not found")
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230518193902.891121-1-nfraprado@collabora.com
The fbdev framebuffer is in system memory. Store the address in
the field 'screen_buffer'. Fixes the following sparse warning.
../drivers/gpu/drm/msm/msm_fbdev.c:124:26: warning: incorrect type in assignment (different address spaces)
../drivers/gpu/drm/msm/msm_fbdev.c:124:26: expected char [noderef] __iomem *screen_base
../drivers/gpu/drm/msm/msm_fbdev.c:124:26: got void *
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230522191701.13406-1-tzimmermann@suse.de
The fbdev framebuffer is I/O memory, so clear it with fb_memset_io().
Fixes the following sparse warning:
../drivers/gpu/drm/gma500/fbdev.c:234:20: warning: incorrect type in argument 1 (different address spaces)
../drivers/gpu/drm/gma500/fbdev.c:234:20: expected void *s
../drivers/gpu/drm/gma500/fbdev.c:234:20: got char [noderef] __iomem *screen_base
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230522190637.7039-1-tzimmermann@suse.de
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
cache. For userspace components needing to fine tune the caching policy
for BO's, a follow up patch will extend the GEM_CREATE uAPI to allow
them specify caching mode at BO creation time.
Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230519051103.3404990-2-fei.yang@intel.com
Reserve some bits in the counter config namespace which will carry the
tile id and prepare the code to handle this.
No per tile counters have been added yet.
v2:
- Fix checkpatch issues
- Use 4 bits for gt id in non-engine counters. Drop FIXME.
- Set MAX GTs to 4. Drop FIXME.
v3: (Ashutosh, Tvrtko)
- Drop BUG_ON that would never fire
- Make enable u64
- Pull in some code from next patch
v4: Set I915_PMU_MAX_GTS to 2 (Tvrtko)
v5: s/u64/u32 where needed (Ashutosh)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230519154946.3751971-7-umesh.nerlige.ramappa@intel.com
Implement support for DSI clock and data lane DN/DP polarity swap by
means of decoding 'lane-polarities' DT property. The controller does
support DN/DP swap of clock lane and all data lanes, the controller
does not support polarity swap of individual data lane bundles, add
a check which verifies all data lanes have the same polarity.
This has been validated on an imx8mm board that actually has the MIPI DSI
clock lanes inverted.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230514114625.98372-2-festevam@gmail.com
