== Series Details ==
Series: drm_managed, leftovers
URL : https://patchwork.freedesktop.org/series/81371/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8965_full -> Patchwork_18445_full
Summary
---
**FAILURE**
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/81336/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8965_full -> Patchwork_18444_full
Summary
---
**FAILURE**
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev7)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8965_full -> Patchwork_18443_full
Summary
== Series Details ==
Series: drm/i915: Pimp DP DFP handling (rev2)
URL : https://patchwork.freedesktop.org/series/72928/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8965_full -> Patchwork_18442_full
Summary
---
Will try to look at this today, if I don't have the time though I'll definitely
have the time on Tuesday
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Attempt to deal with DP downstream facing ports (DFP) more
> thoroughly. This involves reading more of the
On Fri, 2020-09-04 at 09:24 -0400, Rodrigo Vivi wrote:
> On Mon, Aug 31, 2020 at 07:38:57PM -0400, Lyude Paul wrote:
> > topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1:
> > UAPI Changes:
> >
> > None
> >
> > Cross-subsystem Changes:
> >
> > * Moves a bunch of miscellaneous DP code from
On Fri, Sep 04, 2020 at 02:56:05PM +0300, Petri Latvala wrote:
> On Fri, Sep 04, 2020 at 12:09:18PM +0100, Liviu Dudau wrote:
> > On Sun, Aug 30, 2020 at 01:44:06PM -0400, Rodrigo Siqueira wrote:
> > > Hi,
> >
> > Hi,
> >
> > Can this series be merged?
>
> Thanks for the poke. It's merged now.
== Series Details ==
Series: drm_managed, leftovers
URL : https://patchwork.freedesktop.org/series/81371/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8965 -> Patchwork_18445
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm_managed, leftovers
URL : https://patchwork.freedesktop.org/series/81371/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/drm_drv.c:424:6:
On Fri, Sep 4, 2020 at 4:40 PM Daniel Vetter wrote:
>
> Upcasting using a container_of macro is more typesafe, faster and
> easier for the compiler to optimize.
>
> Cc: Eugeniy Paltsev
> Signed-off-by: Daniel Vetter
> Cc: Alexey Brodkin
>From the old thread Sam just confirmed he's ok with
== Series Details ==
Series: drm_managed, leftovers
URL : https://patchwork.freedesktop.org/series/81371/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7e79337308df drm/armada: Use devm_drm_dev_alloc
-:68: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal
Hi Daniel.
On Fri, Sep 04, 2020 at 03:42:44PM +0200, Daniel Vetter wrote:
> On Fri, Apr 24, 2020 at 6:46 PM Sam Ravnborg wrote:
> >
> > Hi Daniel.
> >
> > On Wed, Apr 15, 2020 at 09:40:15AM +0200, Daniel Vetter wrote:
> > > Upcasting using a container_of macro is more typesafe, faster and
> > >
Because it is.
v2: Delete now unused crtc funcs (0day)
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
MAINTAINERS | 2 +-
drivers/gpu/drm/Kconfig | 2 --
drivers/gpu/drm/Makefile
At less than 500 lines total feels like the right thing to do.
Also noticed that the simple wrapper around drm_connector_cleanup can
be dropped.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Cc: Alexey Brodkin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
Simple pipe helpers only have an enable and disable hook, no more
mode_set_nofb. Call it from our enable hook to align with that
conversions.
Atomic helpers always call mode_set_nofb and enable together, so
there's no functional change here.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Really not worth the function, much less the separate file now that
almost all the code is gone.
Cc: Eugeniy Paltsev
Cc: Alexey Brodkin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 1 -
drivers/gpu/drm/arc/arcpgu_drv.c | 12
It's redundant, drm core guarantees that state->fb is set iff
state->crtc is set.
v2: I had a misconception about simple helpers here and thought they
filter this out. They don't. Issue reported by Eugeniy.
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
That way we can get rid of this final piece of init code, and use the
simple pipe helpers as intended.
v2: Fix indent (Sam)
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_drv.c | 53 ++--
Really not big anymore.
Note that we no longer clamp all errors to ENODEV, highlighted by Sam.
v2: Fixup update function, bug reported by Eugeniy
v3: Delete now unused crtc funcs (0day)
v4: Move encoder removal to right patch (Sam).
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Sam
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 2 ++
drivers/gpu/drm/arc/arcpgu_crtc.c | 4 ++--
drivers/gpu/drm/arc/arcpgu_drv.c
Leftover from the conversion to the generic fbdev emulation.
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index
We can now also delete drm_dev_init, now that vkms, vgem and i915
selftests are resolved.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 41 +++---
drivers/gpu/drm/drm_internal.h | 1 +
drivers/gpu/drm/drm_managed.c | 13 ---
With autocleanup through drm_device management we can delete all the
code. Possible now that there's no confusion against devm_kzalloc'ed
structures anymore.
I inlined arcpgu_setup_mode_config because it's tiny and the newly
needed return value handling would have been more ...
Acked-by: Sam
drm_connector_register does nothing before drm_dev_register(), it
is meant for hotpluggable connectors only. Same for the unregister side.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_sim.c | 2 --
1 file changed, 2
Really straighforward, only slight issue is that the sim connector is
created after the pipe is set up, so can't use the helpers perfectly
yet. Subsequent patches will fix that.
Aside from lots of deleting code no functional changes in here.
v2: Delete now unused crtc funcs (0day)
v3: Move
- Need to embedded the drm_device, but for now we keep the usual
pointer chasing.
- No more devm_kzalloc, which fixes a lifetime issues on driver
remove.
- No more drm_dev_put, that's done by devm_ now.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey
This is a prep step to convert arc over to the simple kms helpers, for
now we just use this as an embedding container to drop all the various
allocations. Big change is the removal of the various devm_kzalloc,
which have the wrong lifetimes anyway.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
The big change is device_add so that device_del can auto-cleanup
devres resources. This allows us to use devm_drm_dev_alloc, which
removes the last user of drm_dev_init.
v2: Rebased
v3: use devres_open/release_group so we can use devm without real
hacks in the driver core or having to create an
Removes the last devm_kzalloc, which means we're now prepared to use
drmm_mode_config_cleanup!
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 +
drivers/gpu/drm/arc/arcpgu_sim.c | 14 +-
2 files
Just some prep work before we rework the lifetime handling, which
requires replacing all the drm_dev_put in selftests by something else.
v2: Don't go with a static inline, upsets the header tests and
separation.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c
Since aspeed doesn't use devm_kzalloc anymore we can use the managed
mode config cleanup.
v2: Keep call order as suggested by Sam.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: linux-asp...@lists.ozlabs.org
Cc:
This means we also need to slightly restructure the exit code, so that
final cleanup of the drm_device is triggered by unregistering the
platform device. Note that devres is both clean up when the driver is
unbound (not the case for vgem, we don't bind), and also when unregistering
the device
Gets rid of drmm_add_final_kfree, which I want to unexport so that it
stops confusion people about this transitional state of rolling drm
managed memory out.
This also fixes the missing drm_dev_put in the error path of the probe
code.
Signed-off-by: Daniel Vetter
Cc: Hyun Kwon
Cc: Laurent
This means we also need to slightly restructure the exit code, so that
final cleanup of the drm_device is triggered by unregistering the
platform device. Note that devres is both clean up when the driver is
unbound (not the case for vkms, we don't bind), and also when unregistering
the device
Hi all,
After quite a long interruption with looking too much at dma-fence I've
found some time (and motivation due to questions from people who got
confused by the intermediate state) to polish this off. Changes:
- arc changes moved to the end, since they're not really critical. Iirc
there's
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 4 ++--
drivers/gpu/drm/armada/armada_debugfs.c | 2 +-
drivers/gpu/drm/armada/armada_drm.h | 2
Also remove the now no longer needed build bug on since that's already
not needed anymore with drmm_add_final_kfree. Conversion to managed
drm_device cleanup is easy, the final drm_dev_put() is already the
last thing in both the bind unbind as in the unbind flow.
Also, this relies on component.c
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/81336/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8965 -> Patchwork_18444
Summary
---
**SUCCESS**
No
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/81336/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/81336/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0a3f079e9a9b drm/i915: Expose list of clients in sysfs
-:84: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev7)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8965 -> Patchwork_18443
Summary
---
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev7)
URL : https://patchwork.freedesktop.org/series/74386/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
On Fri, Apr 24, 2020 at 6:46 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Wed, Apr 15, 2020 at 09:40:15AM +0200, Daniel Vetter wrote:
> > Upcasting using a container_of macro is more typesafe, faster and
> > easier for the compiler to optimize.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Alexey
Hi Dave & Daniel,
Here goes the GT pull request for v5.10. It's the same patches as
previously at "topic/drm-intel-gem-next", one dropped and a few
re-ordered while creating the "drm-intel-gt-next" branch. So the
patches have been part of drm-tip already for weeks.
More about the PR itself at
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
On Mon, Aug 31, 2020 at 07:38:57PM -0400, Lyude Paul wrote:
> topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1:
> UAPI Changes:
>
> None
>
> Cross-subsystem Changes:
>
> * Moves a bunch of miscellaneous DP code from the i915 driver into a set
> of shared DRM DP helpers
>
> Core
== Series Details ==
Series: drm/i915: Pimp DP DFP handling (rev2)
URL : https://patchwork.freedesktop.org/series/72928/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8965 -> Patchwork_18442
Summary
---
**SUCCESS**
From: Tvrtko Ursulin
Adds support for per-client engine busyness stats i915 exports in sysfs
and produces output like the below:
==
intel-gpu-top - 935/ 935 MHz;0% RC6; 14.73 Watts; 1097 irqs/s
IMC reads:
From: Tvrtko Ursulin
Intel_gpu_top changes to show per client and per engine class busyness.
Tvrtko Ursulin (1):
intel-gpu-top: Support for client stats
tools/intel_gpu_top.c | 539 +-
1 file changed, 528 insertions(+), 11 deletions(-)
--
2.25.1
== Series Details ==
Series: drm/i915: Pimp DP DFP handling (rev2)
URL : https://patchwork.freedesktop.org/series/72928/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On 04/09/2020 07:26, Lucas De Marchi wrote:
On Tue, Sep 1, 2020 at 8:25 AM Tvrtko Ursulin
wrote:
On 01/09/2020 16:09, Tvrtko Ursulin wrote:
Hi,
On 26/08/2020 02:11, Lucas De Marchi wrote:
Hi,
Any update on this? It now conflicts in a few places so it needs a
rebase.
I don't see any
From: Tvrtko Ursulin
When available prefer context tracked context busyness because it provides
visibility into currently executing contexts as well.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drm_client.c | 68 --
1 file changed, 63 insertions(+), 5
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not
From: Tvrtko Ursulin
Expose per-client and per-engine busyness under the previously added sysfs
client root.
The new files are one per-engine instance and located under the 'busy'
directory. Each contains a monotonically increasing nano-second resolution
times each client's jobs were executing
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
To enable lockless access to client name and pid data from the following
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
---
From: Tvrtko Ursulin
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
purposes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 12 +++-
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
v2:
* Don't bother supporting selftests contexts from debugfs. (Chris)
v3:
* Trivial rebase.
From: Tvrtko Ursulin
Another re-spin of the per-client engine busyness series. Highlights from this
version:
* Small fix for cyclic client id allocation.
* Otherwise just a rebase to catch up with drm-tip.
Internally we track time spent on engines for each struct intel_context. This
can
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
On Fri, Sep 04, 2020 at 12:09:18PM +0100, Liviu Dudau wrote:
> On Sun, Aug 30, 2020 at 01:44:06PM -0400, Rodrigo Siqueira wrote:
> > Hi,
>
> Hi,
>
> Can this series be merged?
Thanks for the poke. It's merged now.
> Neither me nor Brian managed to get accepted
> in the i-g-t committers list,
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
-Add a vfunc for skl_program_async_surface_address
Enable asynchronous flips in i915 for gen9+ platforms.
v2: -Async flip enablement should be a stand alone patch (Paulo)
v3: -Move the patch to the end of the serires (Paulo)
v4: -Rebased.
v5: -Rebased.
v6: -Rebased.
v7: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Add the details of the implementation of asynchronous flips for i915.
v7: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
Documentation/gpu/i915.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)
v3:
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
v4: -Add separate plane hook for async flip case (Ville)
v5: -Rebased.
v6: -Move the plane hook to separate patch. (Paulo)
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
v2: -Moved the async check above vblank_get as it
was causing issues for PSR.
v3: -No need to wait for vblank to pass, as this wait was causing a
16ms delay
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page flips will also boost the FPS of Mesa benchmarks.
v2: -Few patches have been squashed and patches have been
From: Ville Syrjälä
For platforms that can't do native 4:2:0 outout we may still be
able to do it by getting the DP->HDMI protocol converter to
perform the 4:4:4->4:2:0 downsamling for us. In this case we
have to configure our hardware to output YCbCr 4:4:4, which we've
already hooked up so all
From: Ville Syrjälä
The downstream facing port caps in the DPCD can give us a hint
as to what kind of display mode the sink can use if it doesn't
have an EDID. Use that information to pick a suitable mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 54
From: Ville Syrjälä
Deal with more cases in drm_dp_downstream_max_bpc():
- DPCD 1.0 -> assume 8bpc for non-DP
- DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
- DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is crap
- anything else -> assume 8bpc
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Add helpers to get the TMDS clock limits for HDMI/DVI downstream
facing ports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 116
include/drm/drm_dp_helper.h | 6 ++
2 files changed, 122 insertions(+)
diff --git
From: Ville Syrjälä
Use drm_dp_downstream_mode() to get a suitable mode for downstream
facing ports which don't have an EDID.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
Move the downstream facing port dotclock check into a new function
(intel_dp_mode_valid_downstream()) so that we have a nice future
place where we can collect other related checks.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 1 +
From: Ville Syrjälä
Add a few helpers to let us better identify which kind of DFP
we're dealing with.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 60 +
include/drm/drm_dp_helper.h | 5 +++
2 files changed, 65 insertions(+)
diff
From: Ville Syrjälä
We want to differentiate between the DFP dotclock and TMDS clock
limits. Let's convert the current thing to just give us the
dotclock limit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 46 +
From: Ville Syrjälä
DP 1.3 and 1.4 introduced some new registers for DP->HDMI protocol
converters. Define those.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_dp_helper.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_dp_helper.h
From: Ville Syrjälä
Account for the TMDS clock limits declared by the DFP/DP++ dongle
when determining what color depth we're going to use.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 63 ---
drivers/gpu/drm/i915/display/intel_hdmi.c | 50
From: Ville Syrjälä
It helps when the logs have a dump of the DFP capabilities.
v2: Move the dumping to the new helper
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c
From: Ville Syrjälä
Stash the downstream facing port max bpc away during
intel_dp_set_edid(). We'll soon need the EDID in there so
we can't figure this out so easily during .compute_config() anymore.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 5 +
From: Ville Syrjälä
DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion.
Let's use that to configure the "HDMI mode" (ie. infoframes vs. not)
based on the capabilities of the sink.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
From: Ville Syrjälä
Non-HDMI sinks shouldn't be sent infoframes. Check for that when
using LSPCON.
FIXME: How do we turn off infoframes once enabled? Do we even
have to?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 --
From: Ville Syrjälä
Use the new helpers to extract the TMDS clock limits from
the downstream facing port and check them in .mode_valid().
TODO: we should check these in .compute_config() too to eg.
determine if we can do deep color on the HDMI side or not
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Pull the "do we want to enable audio?" computation into a small helper
to make intel_hdmi_compute_config() less messy. Will make it easier to
add more checks for this later (eg. we should actually be checking
at the hblank is long enough for audio transmission).
From: Ville Syrjälä
Add helpers to determine whether the DFP supports
YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 44 +
include/drm/drm_dp_helper.h | 8 ++
2 files
From: Ville Syrjälä
Our definitions for the DPCD DFP capabilities are lacking.
Add the missing bits.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_dp_helper.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_dp_helper.h
From: Ville Syrjälä
Attempt to deal with DP downstream facing ports (DFP) more
thoroughly. This involves reading more of the port caps
and dealing with various clock/bpc limitations.
And we try to enable YCbCr 444->420 conversion for HDMI DFPs
which could allow some 4k displays to actually use
On Sun, Aug 30, 2020 at 01:44:06PM -0400, Rodrigo Siqueira wrote:
> Hi,
Hi,
Can this series be merged? Neither me nor Brian managed to get accepted
in the i-g-t committers list, so I cannot push it.
Best regards,
Liviu
>
> A couple of months ago I updated and re-submitted a patchset made by
>
On Wed, 02 Sep 2020, Ville Syrjälä wrote:
> On Wed, Sep 02, 2020 at 05:30:23PM +0300, Jani Nikula wrote:
>> Streamline the modeset init by removing the extra init layer.
>>
>> No functional changes, which means the cleanup path looks hideous.
>>
>> Signed-off-by: Jani Nikula
>> ---
>>
On Sat, Aug 22, 2020 at 05:02:09PM +0100, Chris Wilson wrote:
> Beware that the address size for x86-32 may exceed unsigned long.
>
> [0.368971] UBSAN: shift-out-of-bounds in
> drivers/iommu/intel/iommu.c:128:14
> [0.369055] shift exponent 36 is too large for 32-bit type 'long unsigned
On Tue, Sep 1, 2020 at 8:25 AM Tvrtko Ursulin
wrote:
>
>
> On 01/09/2020 16:09, Tvrtko Ursulin wrote:
> >
> > Hi,
> >
> > On 26/08/2020 02:11, Lucas De Marchi wrote:
> >> Hi,
> >>
> >> Any update on this? It now conflicts in a few places so it needs a
> >> rebase.
> >
> > I don't see any previous
== Series Details ==
Series: series starting with [1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern
2 and 3
URL : https://patchwork.freedesktop.org/series/81316/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8962_full -> Patchwork_18441_full
94 matches
Mail list logo
