| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Cc: Jitao Shi <[email protected]>
Cc: Cong Yang <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.4.Ib501f2eceb62016e09cfb17bca29bde0f605a567@changeid
|
|
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Cc: Konrad Dybcio <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Tested-by: Luca Weiss <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.1.I784238de4810658212a5786b219f128460562a37@changeid
|
|
Allow sti to be built with COMPILE_TEST=y for greater
coverage. Builds fine on x86/x86_64 at least.
Cc: Alain Volmat <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Acked-by: Alain Volmat <[email protected]>
|
|
Include linux/io.h for devm_ioremap().
When built on x86_64 w/ COMPILE_TEST=y:
../drivers/gpu/drm/sti/sti_dvo.c:531:21: error: implicit declaration of function ‘devm_ioremap’ [-Werror=implicit-function-declaration]
531 | dvo->regs = devm_ioremap(dev, res->start,
| ^~~~~~~~~~~~
../drivers/gpu/drm/sti/sti_dvo.c:531:19: error: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
531 | dvo->regs = devm_ioremap(dev, res->start,
| ^
Cc: Alain Volmat <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Acked-by: Alain Volmat <[email protected]>
|
|
Enable power gating for all units and sub-pipes that
are disabled by default.
v2: change the init function name
use symmetric calls for enable/disable pg
re-pharase commit message (Rodrigo)
modify the sub-pipe power gating condition
v3: set hysteresis value for render and media
when GuC PC is disabled
skip CPG for PVC (Vinay)
v4: rebase
Signed-off-by: Riana Tauro <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]> #v2
Reviewed-by: Vinay Belgaumkar <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Standardize power gate registers
No functional changes
v2: change commit message (Rodrigo)
Signed-off-by: Riana Tauro <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
During engine LRC initialization a number of registers need to be
programmed as general setup. This programming is not a "workaround" so
naming the RTP table as "lrc_was" is misleading; switch to the name
"lrc_setup" to more accurately describe what the table is actually for.
Signed-off-by: Matt Roper <[email protected]>
Reviewed-by: Gustavo Sousa <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We can now use more user-friendly platform name instead of
previosly used magic platform enumerator value:
[ ] xe 0000:00:02.0: [drm] Assertion `false` failed!
platform: ALDERLAKE_S ...
[ ] xe 0000:03:00.0: [drm] Assertion `false` failed!
platform: DG2 ...
vs
[ ] xe 0000:00:02.0: [drm] Assertion `false` failed!
platform: 3 ...
[ ] xe 0000:03:00.0: [drm] Assertion `false` failed!
platform: 7 ...
Signed-off-by: Michal Wajdeczko <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We already maintain the platform name as part of the device
descriptor, but in xe_device.info we only store platform enum,
which is not the best for use in any user-facing messages.
Signed-off-by: Michal Wajdeczko <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
xe_res_cursor code does not depend on the alignment. On the other side
unaligned accesses are useful from pread/pwrite point of view.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Nirmoy Das <[email protected]>
|
|
Tests show that user fence signalling requires kind of write barrier,
otherwise not all writes performed by the workload will be available
to userspace. It is already done for render and compute, we need it
also for the rest: video, gsc, copy.
v2: added gsc and copy engines, added fixes and r-b tags
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1488
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Nirmoy Das <[email protected]>
|
|
The DesignWare MIPI DSI controller found RK3128 SoCs supports up to 4 DSI
data lanes. Similar to PX30/RK356x/RV1126 it uses an external D-PHY.
Signed-off-by: Alex Bee <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Jernej Skrabec <[email protected]>
Acked-by: Sui Jingfeng <[email protected]>
Reviewed-by: Andy Yan <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Heiko Stuebner <[email protected]>
Acked-by: Heiko Stuebner <[email protected]>
Acked-by: Andy Yan <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Reviewed-by: Maíra Canal <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The vc4_dummy_plane structure was introduced as a mean to add
mock-specific fields.
However, we never really used it and it's still strictly equivalent to
vc4_plane (which is in the same situation vs drm_plane), so we can
simply remove the vc4_dummy_plane structure and make the mock code
cleaner.
Reviewed-by: Maíra Canal <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Acked-by: Sui Jingfeng <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.
In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.
Both would be much easier if we were to expose the infoframes programmed
in the hardware. It won't be perfect since we have no guarantee that
it's actually what goes through the wire, but it's the best we can do.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Infoframes in KMS is usually handled by a bunch of low-level helpers
that require quite some boilerplate for drivers. This leads to
discrepancies with how drivers generate them, and which are actually
sent.
Now that we have everything needed to generate them in the HDMI
connector state, we can generate them in our common logic so that
drivers can simply reuse what we precomputed.
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.
Both drivers implementing the same property with the same semantics,
plus the userspace having support for it, is proof enough that it's
pretty much a de-facto standard now and we can provide helpers for it.
Let's plumb it into the newly created HDMI connector.
Reviewed-by: Dave Stevenson <[email protected]>
Acked-by: Pekka Paalanen <[email protected]>
Reviewed-by: Sebastian Wick <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is equivalent to the one already found in i915 and vc4.
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The previous patch adds a new hook for HDMI connectors to filter out
configurations based on the TMDS character rate. Let's add some tests to
make sure it works as expected.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.
To make that easier to handle for drivers, let's provide an optional
hook to be implemented by drivers so they can tell the HDMI controller
helpers if a given TMDS character rate is reachable for them or not.
This will then be useful to figure out the best format and bpc count for
a given mode.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The previous patch stores in the connector state the expected TMDS
character rate matching the configuration of the HDMI connector. Let's
add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Most HDMI drivers have some code to calculate the TMDS character rate,
usually to adjust an internal clock to match what the mode requires.
Since the TMDS character rates mostly depends on the resolution, whether
we need to repeat pixels or not, the bpc count and the format, we can
now derive it from the HDMI connector state that stores all those infos
and remove the duplication from drivers.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The previous patch added an helper to compute the TMDS character rate on
an HDMI connector. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.
Let's create a helper to provide that rate taking all parameters into
account.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Now that we track the HDMI output format as part of the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.
Let's add the needed defaults and fields for now.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Now that we're tracking the output bpc count in the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Tested-by: Sui Jingfeng <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the ADL_TVIDEO_DIP_AS_SDP_DATA register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/75a4f817f7c73277b2b8021275ccb9a4f3716953.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the ICL_VIDEO_DIP_PPS_ECC register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/620fd2da6eea334bf9a5d1b93717ca1176c4203e.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the ICL_VIDEO_DIP_PPS_DATA register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/fb7c308dd655d1bc4af44ab9c88b5f5245d8a5d6.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the GLK_TVIDEO_DIP_DRM_DATA register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/bab2d0385b748c34bec262afaf491be881990033.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the HSW_TVIDEO_DIP_VSC_DATA register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/2f0ed82eb9c759feb3978e38f3b2835f359d6d1f.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the HSW_TVIDEO_DIP_GMP_DATA register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/fff766dca0e790a801fb7d1ad78980da69d3b9f7.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the HSW_TVIDEO_DIP_SPD_DATA register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/97412857f7580994ea9c9c0c8f5f778261f7e71b.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the HSW_TVIDEO_DIP_VS_DATA register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/6f676d9b2bce0d4911e888c5efeacaddef98579c.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the HSW_TVIDEO_DIP_AVI_DATA register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/113e40bf4d42a38c1be09a7ce0159dc828356ebc.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the HSW_TVIDEO_DIP_GCP register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/36f0b90f07c7aa78e88fadb375359df39ecd0a77.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the HSW_TVIDEO_DIP_CTL register macro.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/7261777d02eeb94093ed3510989c6809c66d50da.1716808214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
|
We'll need to use drm_mode_obj_find_prop_id() for kunit tests to make
sure a given property has been properly created. Let's export it for
tests only.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.
Let's create a new connector sub-state dedicated to HDMI controllers,
that will eventually store everything we need.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Sui Jingfeng <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|
|
We just introduced a new initialization function for our connectors, so
let's build a kunit test suite for it as well.
Reviewed-by: Dave Stevenson <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Maxime Ripard <[email protected]>
|