On 30/04/2021 19:18, Janusz Krzysztofik wrote:
IGT i915/perf library functions now always operate on sysfs perf
attributes of card0 device node, no matter which DRM device fd a user
passes. The intention was to always switch to primary device node if
a user passes a render device node fd, but th
Hi Hans,
On Wed, Apr 28, 2021 at 11:52:52PM +0200, Hans de Goede wrote:
> +/**
> + * struct drm_connector_oob_hotplug_event_data: OOB hotplug event data
> + *
> + * Contains data about out-of-band hotplug events, signalled through
> + * drm_connector_oob_hotplug_event().
> + */
> +struct drm_conne
Quoting Andreas Friedrich (2021-04-30 13:36:35)
> On Fri, Apr 30, 2021 at 11:31:47AM +0300, Joonas Lahtinen wrote:
>
> Hello Joonas,
>
> thank you for your quick response.
> ...
> > That is a merge commit, it doesn't itself change anything as there were no
> > conflicts. It just indicates that tw
On Fri, 30 Apr 2021, Jani Nikula wrote:
> On Thu, 29 Apr 2021, Lyude Paul wrote:
>> JFYI Jani and Ben: I will be pushing this patch to drm-misc-next sometime
>> today if there's no objections
>
> Thanks for the heads-up, I think this breaks i915. See my review
> comments elsewhere in the thread.
On Mon, 03 May 2021, Jani Nikula wrote:
> On Fri, 30 Apr 2021, Jani Nikula wrote:
>> On Thu, 29 Apr 2021, Lyude Paul wrote:
>>> JFYI Jani and Ben: I will be pushing this patch to drm-misc-next sometime
>>> today if there's no objections
>>
>> Thanks for the heads-up, I think this breaks i915. Se
On Fri, 30 Apr 2021, "Cornij, Nikola" wrote:
> I'll fix the dpcd part to use kHz on Monday
I'd appreciate that, thanks. I think it is the better interface.
> My apologies as well, not only for coming up with the wrong patch in
> first place, but also for missing to CC all the maintainers.
The d
eb_copy_relocations() only do unsafe_put_user(), it only
requires write access to user.
Use user_write_access_begin() instead of user_access_begin().
Signed-off-by: Christophe Leroy
---
Resending with mm list in addition
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 +++---
1 file changed
== Series Details ==
Series: drm/i915: lpsp with hdmi/dp outputs (rev2)
URL : https://patchwork.freedesktop.org/series/77866/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10034 -> Patchwork_20044
Summary
---
**SUCCE
Thanks for the feedback. I got some questions below.
> On Thu, Apr 29, 2021 at 02:05:53PM +0200, Werner Sembach wrote:
>> When encoder validation of a display mode fails, retry with less bandwidth
>> heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
>> to support 4k60Hz out
Hi, Maarten,
I saw this the other day while working on the TTM conversion:
5925.509765] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:928
[ 5925.509769] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid:
21608, name: kworker/2:1
[ 5925.509772] INFO: lockdep
== Series Details ==
Series: drm/i915: Be more gentle with exiting non-persistent context (rev2)
URL : https://patchwork.freedesktop.org/series/89644/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10036 -> Patchwork_20045
S
== Series Details ==
Series: drm/i915: lpsp with hdmi/dp outputs (rev2)
URL : https://patchwork.freedesktop.org/series/77866/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10034_full -> Patchwork_20044_full
Summary
---
Op 03-05-2021 om 13:57 schreef Thomas Hellström:
> Hi, Maarten,
>
> I saw this the other day while working on the TTM conversion:
>
> 5925.509765] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:928
> [ 5925.509769] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, p
== Series Details ==
Series: drm/dp_mst: Use the correct max source link rate for i915
URL : https://patchwork.freedesktop.org/series/89712/
State : failure
== Summary ==
Applying: drm/dp_mst: Use the correct max source link rate for i915
Using index info to reconstruct a base tree...
M
== Series Details ==
Series: drm/i915: cdclk cleanups
URL : https://patchwork.freedesktop.org/series/89700/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10036 -> Patchwork_20046
Summary
---
**SUCCESS**
No regress
== Series Details ==
Series: drm/i915: Use the correct max source link rate for MST
URL : https://patchwork.freedesktop.org/series/89717/
State : failure
== Summary ==
Applying: drm/i915: Use the correct max source link rate for MST
Using index info to reconstruct a base tree...
M driver
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, April 30, 2021 11:10 PM
> To: Gupta, Anshuman
> Cc: intel-gfx@lists.freedesktop.org; Kai Vehmanen
> ; Shankar, Uma
> Subject: Re: [RFC v2] drm/i915: lpsp with hdmi/dp outputs
>
> On Fri, Apr 30, 2021 at 05:23:55PM +0530, Ansh
== Series Details ==
Series: drm/i915/display/tgl+: Add new sequence step for MST + FEC
URL : https://patchwork.freedesktop.org/series/89714/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10036 -> Patchwork_20048
Summary
--
On Fri, Apr 23, 2021 at 9:46 PM Robin Murphy wrote:
>
> On 2021-04-22 09:15, Claire Chang wrote:
> > The restricted DMA pool is preferred if available.
> >
> > The restricted DMA pools provide a basic level of protection against the
> > DMA overwriting buffer contents at unexpected times. However,
== Series Details ==
Series: series starting with [1/2] drm/dp: Handle zeroed port counts in
drm_dp_read_downstream_info()
URL : https://patchwork.freedesktop.org/series/89719/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10036 -> Patchwork_20050
Reviewed-by: Juha-Pekka Heikkila
On 1.5.2021 3.28, Imre Deak wrote:
Make sure that the XYUV format is handled correctly when it's used
with a MC_CCS modifier framebuffer. Besides this format not working, the
driver will also return an incorrect error value when trying to use it,
indicating
Hi,
On 5/3/21 10:00 AM, Heikki Krogerus wrote:
> Hi Hans,
>
> On Wed, Apr 28, 2021 at 11:52:52PM +0200, Hans de Goede wrote:
>> +/**
>> + * struct drm_connector_oob_hotplug_event_data: OOB hotplug event data
>> + *
>> + * Contains data about out-of-band hotplug events, signalled through
>> + * dr
== Series Details ==
Series: drm/i915: cdclk cleanups
URL : https://patchwork.freedesktop.org/series/89700/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10036_full -> Patchwork_20046_full
Summary
---
**SUCCESS**
On Mon, May 03, 2021 at 01:39:04PM +0200, Werner Sembach wrote:
> Thanks for the feedback. I got some questions below.
> > On Thu, Apr 29, 2021 at 02:05:53PM +0200, Werner Sembach wrote:
> >> When encoder validation of a display mode fails, retry with less bandwidth
> >> heavy YCbCr420 color mode,
Hi All,
Here is v2 of my work on making DP over Type-C work on devices where the
Type-C controller does not drive the HPD pin on the GPU, but instead
we need to forward HPD events from the Type-C controller to the DRM driver.
Changes in v2:
- Replace the bogus "drm/connector: Make the drm_sysfs c
Give connector sysfs devices there own device_type, this allows us to
check if a device passed to functions dealing with generic devices is
a drm_connector or not.
A check like this is necessary in the drm_connector_acpi_bus_match()
function added in the next patch in this series.
Signed-off-by:
Add a fwnode pointer to struct drm_connector and register an acpi_bus_type
for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled).
The adding of the fwnode pointer allows drivers to associate a fwnode
that represents a connector with that connector.
When the new fwnode pointer p
Add a function to find a connector based on a fwnode.
This will be used by the new drm_connector_oob_hotplug_event()
function which is added by the next patch in this patch-set.
Changes in v2:
- Complete rewrite to use a global connector list in drm_connector.c
rather then using a class-dev-ite
Add a new drm_connector_oob_hotplug_event() function and
oob_hotplug_event drm_connector_funcs member.
On some hardware a hotplug event notification may come from outside the
display driver / device. An example of this is some USB Type-C setups
where the hardware muxes the DisplayPort data and aux
From: Heikki Krogerus
On Intel platforms we know that the ACPI connector device
node order will follow the order the driver (i915) decides.
The decision is made using the custom Intel ACPI OpRegion
(intel_opregion.c), though the driver does not actually know
that the values it sends to ACPI there
On some Cherry Trail devices, DisplayPort over Type-C is supported through
a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this
case does the PD/alt-mode negotiation itself, rather then everything being
ha
Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
rather then having separate code-paths for this in various places
which call it.
Signed-off-by: Hans de Goede
---
drivers/usb/typec/altmodes/displayport.c | 35 +---
1 file changed, 13 insertions(+), 22 deletion
Use the new drm_connector_find_by_fwnode() and
drm_connector_oob_hotplug_event() functions to let drm/kms drivers
know about DisplayPort over Type-C hotplug events.
Signed-off-by: Hans de Goede
---
Changes in v2:
- Add missing depends on DRM to TYPEC_DP_ALTMODE Kconfig entry
---
drivers/usb/type
The Type-C connector on these devices is connected to DP-2 not DP-1,
so the reference must be to the DD04 child-node of the GPU, rather
then the DD02 child-node.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/intel_cht_int33fe_typec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Overview:
-
This patch series attempts to clean up some of the IOCTL mess we've created
over the last few years. The most egregious bit being context mutability.
In summary, this series:
1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP
2. Drops the entire CONTEXT_CLONE A
This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
ringsize on construction"). This API was originally added for OpenCL
but the compute-runtime PR has sat open for a year without action so we
can still pull it out if we want. I argue we should drop it for three
reasons:
1.
The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels. It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support. However, the
libdrm and Bei
Previously, we were storing the ring size in the ring pointer before it
was actually allocated. We would then guard setting the ring size on
checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really
only saves us a few bytes on something that already burns at least 4K.
Instead, this
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. For years we've had the idea of a watchdog
uAPI floating about. The aim was for media, so that they could set very
tight deadlines for their transcodes jobs, so that if you have a corrupt
bitstream
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git
This API allows one context to grab bits out of another context upon
creation. It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
real userspace. It's used by a few IGT tests and that's it. Since it
doesn't add any
This has never been used by any userspace except IGT and provides no
real functionality beyond parroting back parameters userspace passed in
as part of context creation or via setparam. If the context is in
legacy mode (where you use I915_EXEC_RENDER and friends), it returns
success with zero data
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would he
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to another engine but the balanced engine only has one engine in the
sibling set. This doesn't actually result in a virtual engine.
This functionality was orig
Even though FENCE_SUBMIT is only documented to wait until the request in
the in-fence starts instead of waiting until it completes, it has a bit
more magic than that. If FENCE_SUBMIT is used to submit something to a
balanced engine, we would wait to assign engines until the primary
request was rea
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42 ---
drivers/gpu/drm/i915/i915
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu
As far as I can tell, the only real reason for this is to avoid taking a
reference to the i915_gem_context. The cost of those two atomics
probably pales in comparison to the cost of the ioctl itself so we're
really not buying ourselves anything here. We're about to make context
lookup a tiny bit
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 43 ---
2 files changed, 3
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_con
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other.
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
.../gpu/drm/i915/gem/selftests/mock_con
There's a big comment saying how useful it is but no one is using this
for anything anymore.
It was added in 2bfa996e031b ("drm/i915: Store owning file on the
i915_address_space") and used for debugfs at the time as well as telling
the difference between the global GTT and a PPGTT. In f6e8aa38717
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic. Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
drivers/g
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 267 --
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 119
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
4 files changed, 1
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 304
1 file changed, 304 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ad6e98d8a4fbd..6e5828fe1a792 100644
--- a/drive
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation. This is the one place I could find in the
selftests where we set a VM after the fact.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed,
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.
Signed-off-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gem/selftests/mock_contex
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us get rid of the complex VM setting code.
Signed-off-by: Jason
== Series Details ==
Series: drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON
URL : https://patchwork.freedesktop.org/series/89639/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10027 -> Patchwork_20030
== Series Details ==
Series: drm/i915: Fix wrong name announced on FB driver switching
URL : https://patchwork.freedesktop.org/series/89663/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10027_full -> Patchwork_20039_full
S
== Series Details ==
Series: drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON
URL : https://patchwork.freedesktop.org/series/89639/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10027_full -> Patchwork_20030_full
===
== Series Details ==
Series: drm/i915/display/tgl+: Add new sequence step for MST + FEC
URL : https://patchwork.freedesktop.org/series/89714/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10036_full -> Patchwork_20048_full
Re-reported successfully.
-Original Message-
From: Janusz Krzysztofik
Sent: Friday, April 30, 2021 1:18 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Fix wrong name announced on FB
driver switching
On piątek, 30 kwiet
Re-reported successfully.
From: Nautiyal, Ankit K
Sent: Friday, April 30, 2021 4:24 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Subject: RE: ✗ Fi.CI.IGT: failure for drm/i915: Use correct downstream caps for
check Src-Ctl mode for PCON
Hi Lakshmi,
The given possible regres
Stable team, please backport the upstream commits
7962893ecb85 ("drm/i915: Disable runtime power management during shutdown")
to the v5.11 stable kernel, they fix a system shutdown failure.
References:
https://lore.kernel.org/intel-gfx/042237f49ed1fd719126a3407d7c909e49addbea.ca...@gmx.net
Repo
== Series Details ==
Series: series starting with [1/2] drm/dp: Handle zeroed port counts in
drm_dp_read_downstream_info()
URL : https://patchwork.freedesktop.org/series/89719/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10036_full -> Patchwork_20050_full
==
On Mon, May 03, 2021 at 07:40:01PM +0300, Imre Deak wrote:
> Stable team, please backport the upstream commits
>
> 7962893ecb85 ("drm/i915: Disable runtime power management during shutdown")
>
> to the v5.11 stable kernel, they fix a system shutdown failure.
>
> References:
> https://lore.kerne
On Mon, May 03, 2021 at 06:53:43PM +0200, Greg KH wrote:
> On Mon, May 03, 2021 at 07:40:01PM +0300, Imre Deak wrote:
> > Stable team, please backport the upstream commits
> >
> > 7962893ecb85 ("drm/i915: Disable runtime power management during shutdown")
> >
> > to the v5.11 stable kernel, they
== Series Details ==
Series: Simplify intel_setup_outputs (rev5)
URL : https://patchwork.freedesktop.org/series/88988/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10038 -> Patchwork_20051
Summary
---
**SUCCESS**
[why]
Link rate in kHz is what is eventually required to calculate the link
bandwidth, which makes kHz a more generic unit. This should also make
forward-compatibility with new DP standards easier.
[how]
- Replace 'link rate DPCD code' with 'link rate in kHz' when used with
drm_dp_mst_topology_mgr
On Mon, 03 May 2021, Nikola Cornij wrote:
> [why]
> Link rate in kHz is what is eventually required to calculate the link
> bandwidth, which makes kHz a more generic unit. This should also make
> forward-compatibility with new DP standards easier.
>
> [how]
> - Replace 'link rate DPCD code' with '
On Thu, 29 Apr 2021, Ankit Nautiyal wrote:
> Fix the typo in DPCD caps used for checking SRC CTL mode of
> HDMI2.1 PCON
>
> Fixes: 04b6603d13be (drm/i915/display: Configure HDMI2.1 Pcon for FRL
> only if Src-Ctl mode is available)
Correct format for Fixes: is this:
Fixes: 04b6603d13be ("drm/i915
On Thu, 29 Apr 2021, Janusz Krzysztofik
wrote:
> Commit 7a0f9ef9703d ("drm/i915: Use drm_fb_helper_fill_info")
> effectively changed our FB driver name from "inteldrmfb" to
> "i915drmfb". However, we are still using the old name when kicking out
> a firmware fbdev driver potentially bound to our
On Fri, 30 Apr 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the hand rolled rmw sequences with intel_de_rmw().
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff
On Fri, 30 Apr 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> A few easy cleanups to the cdclk code.
On the series,
Reviewed-by: Jani Nikula
>
> Ville Syrjälä (5):
> drm/i915: Extract some helpers to compute cdclk register values
> drm/i915: Use intel_de_rmw() in bdw cdclk programm
On Fri, 30 Apr 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Hoist the intel_de.h include from intel_display_types.h one
> level up. I need this in order to untangle the include order
> so that I can add tracepoints into intel_de.h.
Wonder why this isn't getting test results.
>
> This li
On Wed, 28 Apr 2021, Anusha Srivatsa wrote:
> Use new format of debug messages across intel_csr.
>
> While at it, change some function definitions which now
> need dev_priv for drm_err and drm_info etc.
>
> Cc: Lucas De Marchi
> Suggested-by: Lucas De Marchi
> Signed-off-by: Anusha Srivatsa
> -
On Wed, 28 Apr 2021, Anusha Srivatsa wrote:
> We check for dmc_payload being there at various points in the driver.
> Replace it with the helper.
Yes please!
>
> While at it moving bits related to CSR to intel_csr.h
>
> Cc: Lucas De Marchi
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
AMDGPU had nearly the exact same issue. This problem description is
therefore copied fro
On Wed, 28 Apr 2021, Anusha Srivatsa wrote:
> This series adds the prep work needed before the
> actual Pipe DMC implementation.
When should we rename csr to dmc all over the place?
BR,
Jani.
>
> Anusha Srivatsa (3):
> drm/i915/csr: s/DRM_ERROR/drm_err
> drm/i915/csr: Add intel_csr_has_dmc_
== Series Details ==
Series: drm/i915/tgl+: Add the missing MC CCS/XYUV format support
URL : https://patchwork.freedesktop.org/series/89721/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10038 -> Patchwork_20052
Summary
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
AMDGPU had nearly the exact same issue. This problem description is
therefore copied fro
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
AMDGPU had nearly the exact same issue. This problem description is
therefore copied fro
Add a missing check that could potentially lead to an unarchivable mode being
validated.
Signed-off-by: Werner Sembach
---
>From 54fa706f0a5f260a32af5d18b9622ceebb94c12e Mon Sep 17 00:00:00 2001
From: Werner Sembach
Date: Mon, 3 May 2021 14:42:36 +0200
Subject: [PATCH 2/4] Add missing check
--
Couples the decission between RGB and YCbCr420 mode and the check if the port
clock can archive the required frequency. Other checks and configuration steps
that where previously done in between can also be done before or after.
This allows for are cleaner implementation of retrying different colo
Moves some checks that later will be performed 2 times to an own fuction. This
avoids duplicate code later on.
Signed-off-by: Werner Sembach
---
>From 1c529783eb2ec02099d1ed2ab9257b008cb6f040 Mon Sep 17 00:00:00 2001
From: Werner Sembach
Date: Mon, 3 May 2021 14:35:39 +0200
Subject: [PATCH 1/4]
On Sat, May 01, 2021 at 10:27:03AM -0500, Jason Ekstrand wrote:
On April 30, 2021 23:01:44 "Dixit, Ashutosh"
wrote:
On Fri, 30 Apr 2021 19:19:59 -0700, Umesh Nerlige Ramappa wrote:
On Fri, Apr 30, 2021 at 07:35:41PM -0500, Jason Ekstrand wrote:
On April 30, 2021 18:00:58
Hi Jason,
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 drm-exynos/exynos-drm-next
next-20210503]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.12]
[If your patch is
== Series Details ==
Series: drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON
URL : https://patchwork.freedesktop.org/series/89639/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10027_full -> Patchwork_20030_full
===
Hi Jason,
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 drm-exynos/exynos-drm-next
next-20210503]
[cannot apply to tegra-drm/drm/tegra/for-next v5.12]
[If your patch is applied to the wrong git
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Don't include intel_de.h from
intel_display_types.h (rev2)
URL : https://patchwork.freedesktop.org/series/89698/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10039 -> Patchwork_20053
===
== Series Details ==
Series: drm + usb-type-c: Add support for out-of-band hotplug notification
(rev2)
URL : https://patchwork.freedesktop.org/series/89604/
State : failure
== Summary ==
Applying: drm/connector: Give connector sysfs devices there own device_type
Applying: drm/connector: Add a
== Series Details ==
Series: drm/i915/gem: Use user_write_access_begin() instead of
user_access_begin() (rev2)
URL : https://patchwork.freedesktop.org/series/87834/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10039 -> Patchwork_20054
== Series Details ==
Series: drm/i915/gem: ioctl clean-ups (rev4)
URL : https://patchwork.freedesktop.org/series/89443/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8d290e6238e7 drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
-:177: WARNING:FILE_PATH_CHANGES: added, moved or delete
== Series Details ==
Series: drm/i915/gem: ioctl clean-ups (rev4)
URL : https://patchwork.freedesktop.org/series/89443/
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/i915/gem/i
== Series Details ==
Series: drm/i915/gem: ioctl clean-ups (rev4)
URL : https://patchwork.freedesktop.org/series/89443/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_context_types.h:201: warning: Function
parameter or member 'le
1 - 100 of 116 matches
Mail list logo
