On Sat, Oct 16, 2021 at 12:59:46AM +0300, Jani Nikula wrote:
> On Fri, 15 Oct 2021, "Souza, Jose" wrote:
> > On Fri, 2021-10-15 at 15:10 +0300, Imre Deak wrote:
> >> Reading out the DP encoders' DPCD during booting or resume is only
> >> required for enabled encoders: such encoders may be
== Series Details ==
Series: series starting with [1/2] drm/i915/pmu: Add a name to the execlists
stats
URL : https://patchwork.freedesktop.org/series/95904/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10744 -> Patchwork_21358
== Series Details ==
Series: drm/i915: Update memory bandwidth formulae (rev9)
URL : https://patchwork.freedesktop.org/series/95138/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10744_full -> Patchwork_21357_full
Summary
== Series Details ==
Series: series starting with [1/2] drm/i915/pmu: Add a name to the execlists
stats
URL : https://patchwork.freedesktop.org/series/95904/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
== Series Details ==
Series: series starting with [1/2] drm/i915/pmu: Add a name to the execlists
stats
URL : https://patchwork.freedesktop.org/series/95904/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7d0d1caf5425 drm/i915/pmu: Add a name to the execlists stats
== Series Details ==
Series: drm/i915: Update memory bandwidth formulae (rev8)
URL : https://patchwork.freedesktop.org/series/95138/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10744_full -> Patchwork_21356_full
Summary
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for all engines using shared memory. For each engine, this
info contains:
-
In preparation for GuC pmu stats, add a name to the execlists stats
structure so that it can be differentiated from the GuC stats.
Signed-off-by: Umesh Nerlige Ramappa
Acked-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 14 +++---
On Fri, 15 Oct 2021 14:46:20 -0700, John Harrison wrote:
>
> On 10/15/2021 07:52, Dixit, Ashutosh wrote:
> > On Thu, 14 Oct 2021 12:42:38 -0700, wrote:
> >> + /*
> >> + * These tests are for a specific scheduling model which is
> >> + * not currently implemented by
On Fri, 15 Oct 2021 14:54:34 -0700, wrote:
>
> diff --git a/tests/i915/gem_exec_fair.c b/tests/i915/gem_exec_fair.c
> index ef5a450f6..5cbb48f5a 100644
> --- a/tests/i915/gem_exec_fair.c
> +++ b/tests/i915/gem_exec_fair.c
> @@ -1314,6 +1314,12 @@ igt_main
>
On Fri, 15 Oct 2021, "Souza, Jose" wrote:
> On Fri, 2021-10-15 at 15:10 +0300, Imre Deak wrote:
>> Reading out the DP encoders' DPCD during booting or resume is only
>> required for enabled encoders: such encoders may be modesetted during
>> the initial commit and the link training this involves
From: John Harrison
The gem_exec_fair test is specifically testing scheduler algorithm
performance. However, GuC does not implement the same algorithm as
execlist mode and this test is not applicable. So, until sw arch
approves a new algorithm and it is implemented in GuC, stop running
the test.
On 10/15/2021 07:52, Dixit, Ashutosh wrote:
On Thu, 14 Oct 2021 12:42:38 -0700, wrote:
+ /*
+* These tests are for a specific scheduling model which is
+* not currently implemented by GuC. So skip on GuC platforms.
+*/
+
== Series Details ==
Series: drm/i915: Update memory bandwidth formulae (rev9)
URL : https://patchwork.freedesktop.org/series/95138/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10744 -> Patchwork_21357
Summary
---
== Series Details ==
Series: drm/i915: Fix up DP DFP 4:2:0 handling more
URL : https://patchwork.freedesktop.org/series/95881/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10743_full -> Patchwork_21355_full
Summary
The formulae has been updated to include more variables. Make
sure the code carries the same.
Bspec: 64631, 54023
v2: Make GEN11 follow the default route and fix calculation of
maxdebw(RK)
v3: Fix div by zero on default case
Correct indent for fallthrough(Jani)
v4: Fix div by zero on
== Series Details ==
Series: drm/i915/dp: Skip the HW readout of DPCD on disabled encoders
URL : https://patchwork.freedesktop.org/series/95878/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10743_full -> Patchwork_21353_full
== Series Details ==
Series: drm/i915: Update memory bandwidth formulae (rev8)
URL : https://patchwork.freedesktop.org/series/95138/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10744 -> Patchwork_21356
Summary
---
== Series Details ==
Series: dma-buf: Fix breakages from dma_resv_iter conversion.
URL : https://patchwork.freedesktop.org/series/95877/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10743_full -> Patchwork_21352_full
On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > > According to the
On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > According to the documentation, drm_add_edid_modes
> > > "... Also fills out the _display_info
On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > According to the documentation, drm_add_edid_modes
> > "... Also fills out the _display_info structure and ELD in @connector
> > with any information which can be
On 2021-10-15 07:37, Claudio Suarez wrote:
> a) Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. The amdgpu driver still calls
> drm_detect_hdmi_monitor() to retrieve the same information, which
> is less efficient. Change to
== Series Details ==
Series: linux-next: build failure after merge of the drm-misc tree
URL : https://patchwork.freedesktop.org/series/95874/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10743_full -> Patchwork_21351_full
Hi Dave and Daniel,
Here goes drm-intel-next-2021-10-15:
Likely the last one towards 5.15.
UAPI Changes:
- No Functional change, but a clarification around I915_TILING values (Matt).
Driver Changes:
- Changes around async flip VT-d w/a (Ville)
- Delete bogus NULL check in
On Fri, Oct 15, 2021 at 06:18:34PM +0300, Jani Nikula wrote:
> On Fri, 15 Oct 2021, Ville Syrjälä wrote:
> > On Fri, Oct 15, 2021 at 03:44:48PM +0300, Jani Nikula wrote:
> >> On Fri, 15 Oct 2021, Claudio Suarez wrote:
> >> > Once EDID is parsed, the monitor HDMI support information is available
The formulae has been updated to include more variables. Make
sure the code carries the same.
Bspec: 64631, 54023
v2: Make GEN11 follow the default route and fix calculation of
maxdebw(RK)
v3: Fix div by zero on default case
Correct indent for fallthrough(Jani)
v4: Fix div by zero on
On Fri, Oct 15, 2021 at 03:30:49PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 01:37:13PM +0200, Claudio Suarez wrote:
> > Once EDID is parsed, the monitor HDMI support information is available
> > through drm_display_info.is_hdmi. Retriving the same information with
> >
== Series Details ==
Series: drm/i915: Don't propagate the gen split confusion further
URL : https://patchwork.freedesktop.org/series/95872/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10743_full -> Patchwork_21350_full
I did prefer v2 bit field graphics version comparison over this {from,
until} for the simple reason it had runtime just one AND instead of two
separate CMP but either way also for v3
Reviewed-by: Juha-Pekka Heikkila
On 15.10.2021 1.09, Imre Deak wrote:
Add a table describing all the
On Fri, 2021-10-15 at 15:10 +0300, Imre Deak wrote:
> Reading out the DP encoders' DPCD during booting or resume is only
> required for enabled encoders: such encoders may be modesetted during
> the initial commit and the link training this involves depends on an
> initialized DPCD. For DDI
== Series Details ==
Series: drm/i915: Clean-up bonding debug message.
URL : https://patchwork.freedesktop.org/series/95871/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10743_full -> Patchwork_21349_full
Summary
---
== Series Details ==
Series: drm/i915: Clean up PXP Kconfig info.
URL : https://patchwork.freedesktop.org/series/95869/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10743_full -> Patchwork_21348_full
Summary
---
Am 15.10.21 um 13:57 schrieb Maarten Lankhorst:
Commit 7fa828cb9265 ("dma-buf: use new iterator in dma_resv_test_signaled")
accidentally forgot to test whether the dma-buf is actually signaled, breaking
pretty much everything depending on it.
NAK, the dma_resv_for_each_fence_unlocked() returns
On Fri, 15 Oct 2021, John Harrison wrote:
> On 10/15/2021 07:52, Tvrtko Ursulin wrote:
>> On 04/10/2021 08:36, Jani Nikula wrote:
>>> On Fri, 24 Sep 2021, Ville Syrjälä
>>> wrote:
On Tue, Sep 21, 2021 at 06:50:39PM -0700, Matthew Brost wrote:
> From: Hugh Dickins
>
> 5.15-rc1
On 10/15/2021 07:52, Tvrtko Ursulin wrote:
On 04/10/2021 08:36, Jani Nikula wrote:
On Fri, 24 Sep 2021, Ville Syrjälä
wrote:
On Tue, Sep 21, 2021 at 06:50:39PM -0700, Matthew Brost wrote:
From: Hugh Dickins
5.15-rc1 crashes with blank screen when booting up on two ThinkPads
using i915.
On Thu, 14 Oct 2021, Jani Nikula wrote:
> The link training delays are different and/or available in different
> DPCD offsets depending on:
>
> - Clock recovery vs. channel equalization
> - DPRX vs. LTTPR
> - 128b/132b vs. 8b/10b
> - DPCD 1.4+ vs. earlier
>
> Add helpers to get the correct delays
On Fri, 15 Oct 2021, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 03:44:48PM +0300, Jani Nikula wrote:
>> On Fri, 15 Oct 2021, Claudio Suarez wrote:
>> > Once EDID is parsed, the monitor HDMI support information is available
>> > through drm_display_info.is_hdmi. Retriving the same information
== Series Details ==
Series: drm/i915: Fix up DP DFP 4:2:0 handling more
URL : https://patchwork.freedesktop.org/series/95881/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10743 -> Patchwork_21355
Summary
---
On 04/10/2021 08:36, Jani Nikula wrote:
On Fri, 24 Sep 2021, Ville Syrjälä wrote:
On Tue, Sep 21, 2021 at 06:50:39PM -0700, Matthew Brost wrote:
From: Hugh Dickins
5.15-rc1 crashes with blank screen when booting up on two ThinkPads
using i915. Bisections converge convincingly, but
On Thu, 14 Oct 2021 12:42:38 -0700, wrote:
>
> + /*
> + * These tests are for a specific scheduling model which is
> + * not currently implemented by GuC. So skip on GuC platforms.
> + */
> + devid = intel_get_drm_devid(i915);
> +
== Series Details ==
Series: drm/i915: Move PCH modeset code into its own file
URL : https://patchwork.freedesktop.org/series/95863/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10742_full -> Patchwork_21346_full
Summary
Hi Ville,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip next-20211015]
[cannot apply to airlied/drm-next v5.15-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
== Series Details ==
Series: drm/i915: Fix up DP DFP 4:2:0 handling more
URL : https://patchwork.freedesktop.org/series/95881/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
da10a92856b4 drm/i915/hdmi: Split intel_hdmi_bpc_possible() to source vs. sink
pair
070dfafd959a
== Series Details ==
Series: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
URL : https://patchwork.freedesktop.org/series/95880/
State : failure
== Summary ==
Applying: gpu/drm: make drm_add_edid_modes() consistent when updating
connector->display_info
Applying: drm/amdgpu:
== Series Details ==
Series: drm/i915/dp: Skip the HW readout of DPCD on disabled encoders
URL : https://patchwork.freedesktop.org/series/95878/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10743 -> Patchwork_21353
From: Ville Syrjälä
We lack sufficient state tracking to figure out whether
we want the DFP to perform the RGB->YCbCr conversion for us
or not. So currently we are blindly just enabling that all the
time when supported by the DFP. That is nonsense. So until
we imporve our state tracking for this
From: Ville Syrjälä
Our YCbCr output is always supposed to be limited range BT.709.
That's what we send with native HDMI. The conn_state->colorspace
stuff is entirely independent of that and is not supposed to alter
the generated output in any way. If we want a way to do that then
we need a new
From: Ville Syrjälä
With native HDMI we allow the user to override the mode with
something that may not respect the downstream (sink,dual-mode adapter)
TMDS clock limits. Let's reuse the same logic for DP HDMI DFPs
so that behaviour is more or less uniform.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Hoist the drm_mode_is_420_only() from intel_dp_output_format()
into the caller. This will allow intel_dp_output_format() to be
reused for "4:2:0 also" modes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 13 +++--
1 file changed, 7
From: Ville Syrjälä
Currently we only support "4:2:0 also" modes on native HDMI.
Extend that support for DP as well.
With all the HDMI DFP TMDS clock handling sorted out this
is now going to work for both native DP and DP->HDMI
converters. As with native HDMI we first check if RGB
output is
From: Ville Syrjälä
Rework the HDMI DFP TMDS clock checks to also check at 8bpc.
Previously we only checked the deep color cases. But I suppose
a sink could potentially declare "4:2:0 also" modes that only
actually fit within its own limits when using 4:2:0. Even if
that is too nuts to be real
From: Ville Syrjälä
Consolidate the double pfit call, and reorder things so that
intel_dp_output_format() and intel_dp_compute_link_config() are
back-to-back. They are intimately related, and will need to be
called twice to properly handle the "4:2:0 also" modes.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Prefer to use intel_connector over drm_connector. Also clean
up the related variable names a bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 38 -
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git
From: Ville Syrjälä
Declutter intel_dp_compute_config() a bit by moving the
has_audio computation into a helper. HDMI already does the same thing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 30 -
1 file changed, 20 insertions(+), 10
From: Ville Syrjälä
intel_dp_hdmi_ycbcr420() does account for native DP 4:2:0
output as well, so lets rename it a bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
From: Ville Syrjälä
Currently we just use all the hdmi_deep_color_possible() stuff
to compute whether deep color is possible, and leave the 8bpc
case to do its own thing. That doesn't mesh super well with 4:2:0
handling because we might end up going for 8bpc RGB without
considering that it's
From: Ville Syrjälä
We're currently duplicating the DFP min/max TMDS clock checks
in .mode_valid() and .compute_config(). Extract a helper suitable
for both use cases.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 59 +++--
1 file changed, 26
From: Ville Syrjälä
Currently we only look at the DFPs max TMDS clock limit when
considering whether the mode is valid, or whether we can do
deep color. The sink's max TMDS clock limit may be lower than
the DFPs, so we need to account for it as well.
Closes:
From: Ville Syrjälä
Reuse intel_hdmi_tmds_clock() for DP->HDMI TMDS clock calculations.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 20 +---
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.h | 1 +
3
From: Ville Syrjälä
Just loop over the possible bpc values instead of
using an ugly if construct.
A slight change in behaviour is that we now call
intel_hdmi_{source,sink}_bpc_possible() even for 8bpc,
but that is fine since 8bpc is always supported.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Reorganize the HDMI 4:2:0 handling a bit by introducing
intel_hdmi_output_format(). We already have the DP counterpart
and I want to unify the 4:2:0 handling across both a bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 35
From: Ville Syrjälä
Currently .mode_valid() and .compute_config() have their "4:2:0 also"
logic inverted. Unify things so that we use the same logic on both
sides.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +++--
1 file changed, 7 insertions(+), 6
From: Ville Syrjälä
Rename intel_hdmi_port_clock() into intel_hdmi_tmds_clock(), and
move the 4:2:0 TMDS clock halving into intel_hdmi_tmds_clock() so
the callers don't have to worry about such details.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 25
From: Ville Syrjälä
Introduce a small helper which given the crtc state tells us
whether we're output YCbCr 4:2:0 or not. For native HDMI this
is rather simple as we just look at the output_format. But I
think the helper is beneficial since with DP HDMI DFPs we're
going to need a more complex
From: Ville Syrjälä
intel_hdmi_bpc_possible() is used by the DP code as well where
the native HDMI source limits do not apply. So let's split this
into a pair of functions: one for the source vs. one for the sink.
This is basically reverting some of commit 41828125acd6 ("drm/i915:
Move platform
From: Ville Syrjälä
Currently we're failing to respect the sink's max TMDS clock
in the DP HDMI DFP code, and exceeding them means the sink
won't show a picture [1]. So let's improve the situation by
checking those limits, and generally fixing up a bunch things
in the deep color/4:2:0 related
== Series Details ==
Series: dma-buf: Fix breakages from dma_resv_iter conversion.
URL : https://patchwork.freedesktop.org/series/95877/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10743 -> Patchwork_21352
Summary
On Fri, Oct 15, 2021 at 03:44:48PM +0300, Jani Nikula wrote:
> On Fri, 15 Oct 2021, Claudio Suarez wrote:
> > Once EDID is parsed, the monitor HDMI support information is available
> > through drm_display_info.is_hdmi. Retriving the same information with
> > drm_detect_hdmi_monitor() is less
Hi Ville,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20211015]
[cannot apply to airlied/drm-next v5.15-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note
Op 15-10-2021 om 14:07 schreef Christian König:
> Am 15.10.21 um 13:57 schrieb Maarten Lankhorst:
>> Commit 7fa828cb9265 ("dma-buf: use new iterator in dma_resv_test_signaled")
>> accidentally forgot to test whether the dma-buf is actually signaled,
>> breaking
>> pretty much everything depending
On Fri, 15 Oct 2021, Claudio Suarez wrote:
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi where possible.
>
> This
== Series Details ==
Series: dma-buf: Fix breakages from dma_resv_iter conversion.
URL : https://patchwork.freedesktop.org/series/95877/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f7a9383f94a9 dma-buf: Fix dma_resv_wait_timeout handling of timeout = 0.
3bf852bf1efc dma-buf:
On Fri, Oct 15, 2021 at 01:37:13PM +0200, Claudio Suarez wrote:
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi where
== Series Details ==
Series: linux-next: build failure after merge of the drm-misc tree
URL : https://patchwork.freedesktop.org/series/95874/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10743 -> Patchwork_21351
Summary
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Use this value instead of calling
drm_detect_hdmi_monitor() to avoid a second parse.
This is a TODO task in Documentation/gpu/todo.rst
Signed-off-by: Claudio Suarez
---
According to the documentation, drm_add_edid_modes
"... Also fills out the _display_info structure and ELD in @connector
with any information which can be derived from the edid."
drm_add_edid_modes accepts a struct edid *edid parameter which may have a
value or may be null. When it is not null,
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/tegra/hdmi.c | 6 +-
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information is less
efficient. Change to drm_display_info.is_hdmi
This is a TODO task in Documentation/gpu/todo.rst
Also, correct an inacurracy or bug in
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c |
a) Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. The amdgpu driver still calls
drm_detect_hdmi_monitor() to retrieve the same information, which
is less efficient. Change to drm_display_info.is_hdmi
This is a TODO task in
Copy from the TODO document Documentation/gpu/todo.rst
===
Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
---
Once EDID is parsed, the monitor HDMI support information is available through
drm_display_info.is_hdmi.
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/sti/sti_hdmi.c | 10
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/rockchip/inno_hdmi.c |
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/zte/zx_hdmi.c | 4 ++--
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi where possible
Signed-off-by: Claudio Suarez
---
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/nouveau/dispnv50/disp.c
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi where possible.
This is a TODO task in Documentation/gpu/todo.rst
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/gma500/cdv_intel_hdmi.c
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 6
.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-i915-Move-PCH-modeset-code-into-its-own-file/20211015-151850
base: git://anongit.freedesktop.org/drm-intel for-linux
Reading out the DP encoders' DPCD during booting or resume is only
required for enabled encoders: such encoders may be modesetted during
the initial commit and the link training this involves depends on an
initialized DPCD. For DDI encoders reading out the DPCD is skipped, do
the same on pre-DDI
On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> According to the documentation, drm_add_edid_modes
> "... Also fills out the _display_info structure and ELD in @connector
> with any information which can be derived from the edid."
>
> drm_add_edid_modes accepts a struct edid
== Series Details ==
Series: linux-next: build failure after merge of the drm-misc tree
URL : https://patchwork.freedesktop.org/series/95874/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
de0f37d0d3e1 linux-next: build failure after merge of the drm-misc tree
-:35:
Commit 7fa828cb9265 ("dma-buf: use new iterator in dma_resv_test_signaled")
accidentally forgot to test whether the dma-buf is actually signaled, breaking
pretty much everything depending on it.
Fixes: 7fa828cb9265 ("dma-buf: use new iterator in dma_resv_test_signaled")
Cc: Christian König
Cc:
Urgent fixes!
dma_resv_test_signaled is completely broken, dma_resv_wait_timeout kind of
broken.
Maarten Lankhorst (2):
dma-buf: Fix dma_resv_wait_timeout handling of timeout = 0.
dma-buf: Fix dma_resv_test_signaled.
drivers/dma-buf/dma-resv.c | 20 +++-
1 file changed, 11
Commit ada5c48b11a3 ("dma-buf: use new iterator in dma_resv_wait_timeout")
accidentally started mishandling timeout = 0, by forcing a blocking wait
with timeout = 1 passed to fences. This is not intended, as timeout = 0
may be used for peeking, similar to test_signaled.
Fixes: ada5c48b11a3
== Series Details ==
Series: drm/i915: Don't propagate the gen split confusion further
URL : https://patchwork.freedesktop.org/series/95872/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10743 -> Patchwork_21350
Summary
== Series Details ==
Series: drm/i915: Simplify handling of modifiers (rev10)
URL : https://patchwork.freedesktop.org/series/95579/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10741_full -> Patchwork_21343_full
Summary
1 - 100 of 131 matches
Mail list logo
