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 "Dixit, Ashutosh"
> > wrote:
> >
> > On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
> >
> > Looks
On Fri, Apr 30, 2021 at 07:35:41PM -0500, Jason Ekstrand wrote:
On April 30, 2021 18:00:58 "Dixit, Ashutosh"
wrote:
On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
Looks like the engine can be dropped since all timestamps are in sync.
I
just have one
On April 30, 2021 18:00:58 "Dixit, Ashutosh" wrote:
On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
Looks like the engine can be dropped since all timestamps are in sync. I
just have one more question here. The timestamp itself is 36 bits. Should
the uapi also report the
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 that the second color plane in the framebuffer is set
unexpectedly.
On Fri, 30 Apr 2021 16:00:46 -0700, Dixit, Ashutosh wrote:
>
> On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
> >
> > Looks like the engine can be dropped since all timestamps are in sync. I
> > just have one more question here. The timestamp itself is 36 bits. Should
> > the
On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
>
> Looks like the engine can be dropped since all timestamps are in sync. I
> just have one more question here. The timestamp itself is 36 bits. Should
> the uapi also report the timestamp width to the user OR should I just
>
[AMD Official Use Only - Internal Distribution Only]
I'll fix the dpcd part to use kHz on Monday
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.
-Original Message-
From: Lyude Paul
Sent: Friday, April
Alright - I had Ville double check this and give their A-B on IRC (I just need
to fix the open coded link_rate_to_bw() here). Since this got broken on drm-
misc-next I'm going to go ahead and push the fix there, since I'm not going to
be around next Monday or Tuesday and I don't want to leave i915
Direction on gen >= 9 was to stop using straps and rely on VBT
indicating if the port is present or not. Remove FIXME comment since
this will never be "fixed".
Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 6 --
1 file changed, 6
Instead of poluting the normal code path in intel_display.c, make
intel_bios.c handle the brokenness of the VBT.
Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c| 20
drivers/gpu/drm/i915/display/intel_display.c | 14
Direction on gen9+ was to stop reading the straps and only rely on the
VBT for marking the port presence. This happened while dealing with
WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the
normal flow. See commit 885d3e5b6f08 ("drm/i915/display: fix comment on
skl straps").
First and second patches should be straightforward. Third patch is a
simplification for gen9+ since we are not supposed to check the straps
anymore and rely on VBT.
Last patch hides port F hacks in intel_bios.c so we have a clean init
sequence.
Lucas De Marchi (4):
drm/i915/display: move vbt
Since commit 45c0673aac97 ("drm/i915/bios: start using the
intel_bios_encoder_data directly") we lookup the devdata for each port
in intel_ddi_init() and just return if the port is not present in VBT
(or if we didn't create a fake devdata for it if VBT is not available).
So in intel_display.c we
Noticed this while fixing another issue in drm_dp_read_downstream_info(),
the open coded DP_DOWNSTREAMPORT_PRESENT check here just duplicates what we
already do in drm_dp_is_branch(), so just get rid of it.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 4 +---
1 file changed,
While the DP specification isn't entirely clear on if this should be
allowed or not, some branch devices report having downstream ports present
while also reporting a downstream port count of 0. So to avoid breaking
those devices, we need to handle this in drm_dp_read_downstream_info().
So, to do
On Thu, Apr 29, 2021 at 02:07:58PM -0500, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 7:34 PM Umesh Nerlige Ramappa
wrote:
Perf measurements rely on CPU and engine timestamps to correlate
events of interest across these time domains. Current mechanisms get
these timestamps separately and
[why]
Previously used value was not safe to provide the correct value, i.e. it
could be 0 if not not configured, leading to no MST on this platform.
[how]
Do not use the value from BIOS, but from the structure populated at
encoder initialization time.
Fixes: 98025a62cb00 ("drm/dp_mst: Use
This is a follow-up change to fix incorrectly used max link rate source
capability at MST init time.
Change history:
v1:
- Initial
v2:
- Use local variabale for improved code readability
- Fix the comment to point to the correct sub-directory
Nikola Cornij (1):
drm/i915: Use the
On Fri, 2021-04-30 at 17:22 -0400, Nikola Cornij wrote:
> [why]
> Previously used value was not safe to provide the correct value, i.e. it
> could be 0 if not not configured, leading to no MST on this platform.
>
> [how]
> Do not use the value from BIOS, but from the structure populated at
>
For DP 1.4 sinks + MST + FEC it is required to prevent a FEC stall
signaling.
BSpec: 49190
BSpec: 54128
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 28 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 29
[why]
Previously used value was not safe to provide the correct value, i.e. it
could be 0 if not not configured, leading to no MST on this platform.
[how]
Do not use the value from BIOS, but from the structure populated at
encoder initialization time.
Fixes: 98025a62cb00 ("drm/dp_mst: Use
This is a follow-up change to fix incorrectly used max link rate source
capability at MST init time.
Change history:
v1:
- Initial
Nikola Cornij (1):
drm/dp_mst: Use the correct max source link rate for i915
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 ++---
1 file changed, 2
JFYI for anyone who is interested, I will be respinning my patches for adding
backlight helpers very soon since we've got pretty much all of the prep work
for it upstream now
On Mon, 2021-04-26 at 12:49 +0300, Jani Nikula wrote:
> On Mon, 26 Apr 2021, Rajeev Nandan wrote:
> > Add backlight
On Fri, Apr 30, 2021 at 12:31:27AM +0800, kernel test robot wrote:
> Hi Bernard,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [also build test ERROR on v5.12 next-20210429]
> [If your patch is applied to the wrong git tree,
On Fri, Apr 30, 2021 at 05:23:55PM +0530, Anshuman Gupta wrote:
> DG1 and DISPLAY_VER=13 onwards Audio MMIO/VERBS lies in PG0 power
> well. So in order to detect audio capable DP/HDMI output it doesn't
> require to enable PG3 power well on DG1 and PG2 on DISPLAY_VER=13
> pltform. It will save the
On Fri, Apr 30, 2021 at 6:57 PM Jason Ekstrand wrote:
>
> On Fri, Apr 30, 2021 at 11:33 AM Daniel Vetter wrote:
> >
> > On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand wrote:
> > >
> > > On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 11:35 PM Jason
On Fri, Apr 30, 2021 at 11:33 AM Daniel Vetter wrote:
>
> On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand wrote:
> >
> > On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
> > >
> > > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> > > wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 2:07 PM
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 output, which previously failed silently.
>
> AMDGPU had
On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand wrote:
>
> On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
> >
> > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> > wrote:
> > >
> > > On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 02:01:16PM
On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
> >
> > On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> > >
> > > On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> > > > On Thu, Apr 29, 2021 at 1:56 PM Daniel
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 that breaks handling of
non-card0 devices.
On Fri, Apr 30, 2021 at 6:40 AM Tvrtko Ursulin
wrote:
>
>
> On 29/04/2021 20:16, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 3:01 AM Tvrtko Ursulin
> > wrote:
> >> On 28/04/2021 18:09, Jason Ekstrand wrote:
> >>> On Wed, Apr 28, 2021 at 9:26 AM Tvrtko Ursulin
> >>> wrote:
> On
On Fri, Apr 30, 2021 at 6:18 AM Tvrtko Ursulin
wrote:
>
>
> On 29/04/2021 15:54, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 28/04/2021 18:24, Jason Ekstrand wrote:
> >>> On Wed, Apr 28, 2021 at 10:55 AM Tvrtko Ursulin
> >>> wrote:
>
From: Ville Syrjälä
Replace the hand rolled PLL lock bit waits with intel_de_wait_for_*().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
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 | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
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 | 25 ++
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
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 --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
From: Ville Syrjälä
Extract a few of the switch statements into helper functions to
reduce the pollution in the cdclk programming functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 186 ++---
1 file changed, 88 insertions(+), 98
From: Ville Syrjälä
A few easy cleanups to the cdclk code.
Ville Syrjälä (5):
drm/i915: Extract some helpers to compute cdclk register values
drm/i915: Use intel_de_rmw() in bdw cdclk programming
drm/i915: Use intel_de_rmw() in skl cdclk programming
drm/i915: Use intel_de_rmw() in
From: Ville Syrjälä
We lost the i915_reg_rw tracepoint for a lot of display registers
when we switched from the heavyweight normal register accessors to
the lightweight _fw() variants. See eg. commit dd584fc0711a
("drm/i915: Use I915_READ_FW for plane updates").
Put the tracepoints back so that
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.
This little cocci script did most of the work for me:
@find@
@@
(
intel_de_read(...)
|
On Fri, Apr 30, 2021 at 3:27 PM Tvrtko Ursulin
wrote:
> On 30/04/2021 12:48, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 10:46:40AM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> When a non-persistent context exits we currently mark it as banned in
> >> order to trigger
On Fri, Apr 30, 2021 at 3:32 PM Hans de Goede wrote:
>
> Hi,
>
> On 4/30/21 1:38 PM, Daniel Vetter wrote:
> > On Fri, Apr 30, 2021 at 1:28 PM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 4/29/21 9:09 PM, Daniel Vetter wrote:
> >>> On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.
In doing so we apply a very strict 1ms limit in which the left over job
has to preempt before we issues an engine
p.s.
On 4/30/21 1:38 PM, Daniel Vetter wrote:
Offtopic:
> I'm also not sure why we have to use the kdev stuff here. For other
> random objects we need to look up we're building that functionality on
> that object. It means you need to keep another list_head around for
> that lookup, but that's
Hi,
On 4/30/21 1:38 PM, Daniel Vetter wrote:
> On Fri, Apr 30, 2021 at 1:28 PM Hans de Goede wrote:
>>
>> Hi,
>>
>> On 4/29/21 9:09 PM, Daniel Vetter wrote:
>>> On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
Hi,
On 4/29/21 2:04 PM, Daniel Vetter wrote:
> On
On 30/04/2021 12:48, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 10:46:40AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.
In
On 30/04/2021 14:07, Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 2:44 PM Tvrtko Ursulin
wrote:
On 30/04/2021 13:30, Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:
On 30/04/2021 07:53, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
On Fri, Apr 30, 2021 at 2:44 PM Tvrtko Ursulin
wrote:
>
>
>
> On 30/04/2021 13:30, Daniel Vetter wrote:
> > On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
> > wrote:
> >> On 30/04/2021 07:53, Daniel Vetter wrote:
> >>> On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> >>> wrote:
>
>
On Fri, Apr 30, 2021 at 07:12:53AM +, Gupta, Anshuman wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, April 28, 2021 12:26 AM
> > To: Gupta, Anshuman
> > Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
> > Gaurav, Kumar ; Shankar, Uma
> > ;
On Fri, Apr 30, 2021 at 06:56:10AM +, Gupta, Anshuman wrote:
>
>
> > -Original Message-
> > From: Ceraolo Spurio, Daniele
> > Sent: Thursday, April 29, 2021 2:10 AM
> > To: Ville Syrjälä
> > Cc: Gupta, Anshuman ; Vivi, Rodrigo
> > ; intel-gfx@lists.freedesktop.org; Bommu,
On 30/04/2021 13:30, Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:
On 30/04/2021 07:53, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 02:01:16PM
On Fri, Apr 30, 2021 at 06:31:49AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/fbc: Don't nuke manually around
> flips (rev3)
> URL : https://patchwork.freedesktop.org/series/89517/
> State : success
>
> == Summary ==
>
> CI Bug Log -
On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:
>
>
> On 30/04/2021 07:53, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> > wrote:
> >>
> >> On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> >>>
> >>> On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason
DG1 and DISPLAY_VER=13 onwards Audio MMIO/VERBS lies in PG0 power
well. So in order to detect audio capable DP/HDMI output it doesn't
require to enable PG3 power well on DG1 and PG2 on DISPLAY_VER=13
pltform. It will save the power when DP/HDMI outputs used as
lpsp configuration.
B.Spec: 49233
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 two trees got merged.
...
> If you are able to provide a bisect
== Series Details ==
Series: series starting with [v3,1/5] drm/connector: Create a helper to attach
the hdr_output_metadata property
URL : https://patchwork.freedesktop.org/series/89690/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10032_full -> Patchwork_20043_full
On 30/04/2021 07:53, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
On Thu, Apr 29,
On Thu, Apr 29, 2021 at 06:34:51PM +0100, Tvrtko Ursulin wrote:
>
> On 29/04/2021 17:31, Ville Syrjälä wrote:
> > On Thu, Apr 29, 2021 at 09:35:29AM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > __i915_active_call annotation is required on the retire callback to ensure
> >
On Thu, Apr 29, 2021 at 10:46:40AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> When a non-persistent context exits we currently mark it as banned in
> order to trigger fast termination of any outstanding GPU jobs it may have
> left running.
>
> In doing so we apply a very strict 1ms
On 29/04/2021 20:16, Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 3:01 AM Tvrtko Ursulin
wrote:
On 28/04/2021 18:09, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 9:26 AM Tvrtko Ursulin
wrote:
On 28/04/2021 15:02, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 11:42:31AM +0100, Tvrtko
On Fri, Apr 30, 2021 at 1:28 PM Hans de Goede wrote:
>
> Hi,
>
> On 4/29/21 9:09 PM, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 4/29/21 2:04 PM, Daniel Vetter wrote:
> >>> On Thu, Apr 29, 2021 at 01:54:46PM +0200, Greg
Hi,
On 4/29/21 9:09 PM, Daniel Vetter wrote:
> On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 4/29/21 2:04 PM, Daniel Vetter wrote:
>>> On Thu, Apr 29, 2021 at 01:54:46PM +0200, Greg Kroah-Hartman wrote:
On Thu, Apr 29, 2021 at 01:40:28PM +0200, Daniel Vetter
Hi Lakshmi,
The given possible regression is an existing issue :
https://gitlab.freedesktop.org/drm/intel/-/issues/2867
Possible regressions
* igt@gem_ctx_isolation@preservation-s3@vecs0:
* shard-iclb:
On 29/04/2021 15:54, Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
wrote:
On 28/04/2021 18:24, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 10:55 AM Tvrtko Ursulin
wrote:
On 23/04/2021 23:31, Jason Ekstrand wrote:
Instead of handling it like a context param,
Op 29-04-2021 om 14:01 schreef Maarten Lankhorst:
> We changed the locking hierarchy for both ppgtt and ggtt, so both locks
> should be trylocked inside i915_gem_object_unbind().
>
> Signed-off-by: Maarten Lankhorst
> Fixes: bc6f80cce9ae ("drm/i915: Use trylock in shrinker for ggtt on bsw vt-d
>
On 29/04/2021 18:31, Ville Syrjälä wrote:
On Thu, Apr 29, 2021 at 07:31:43PM +0300, Ville Syrjälä wrote:
On Thu, Apr 29, 2021 at 09:35:29AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
__i915_active_call annotation is required on the retire callback to ensure
correct function
== Series Details ==
Series: series starting with [v3,1/5] drm/connector: Create a helper to attach
the hdr_output_metadata property
URL : https://patchwork.freedesktop.org/series/89690/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10032 -> Patchwork_20043
== Series Details ==
Series: series starting with [v3,1/5] drm/connector: Create a helper to attach
the hdr_output_metadata property
URL : https://patchwork.freedesktop.org/series/89690/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used,
== Series Details ==
Series: series starting with [v3,1/5] drm/connector: Create a helper to attach
the hdr_output_metadata property
URL : https://patchwork.freedesktop.org/series/89690/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
edc37a6f6280 drm/connector: Create a helper
On Thu, Apr 29, 2021 at 09:03:48PM -0700, Matthew Brost wrote:
> On Thu, Apr 29, 2021 at 02:14:19PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 28, 2021 at 01:17:27PM -0500, Jason Ekstrand wrote:
> > > On Wed, Apr 28, 2021 at 1:02 PM Matthew Brost
> > > wrote:
> > > >
> > > > On Wed, Apr 28,
The intel driver uses the same logic to attach the Colorspace property
in multiple places and we'll need it in vc4 too. Let's move that common
code in a helper.
Signed-off-by: Maxime Ripard
---
Changes from v2:
- Rebased on current drm-misc-next
Changes from v1:
- New patch
---
Our driver while supporting HDR didn't send the proper colorimetry info
in the AVI infoframe.
Let's add the property needed so that the userspace can let us know what
the colorspace is supposed to be.
Signed-off-by: Maxime Ripard
---
Changes from v2:
- Rebased on current drm-misc-next
All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.
All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those
From: Dave Stevenson
Now that we can export deeper colour depths, add in the signalling
for HDR metadata.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
Changes from v2:
- Rebased on current drm-misc-next
Changes from v1:
- Rebased on latest drm-misc-next tag
---
All the drivers that implement HDR output call pretty much the same
function to initialise the hdr_output_metadata property, and while the
creation of that property is in a helper, every driver uses the same
code to attach it.
Provide a helper for it as well
Reviewed-by: Harry Wentland
Hi Dave & Daniel -
One more fix for -rc1.
drm-intel-next-fixes-2021-04-30:
drm/i915 GVT fixes for v5.13-rc1:
- Fix a possible division by zero in vgpu display rate calculation
BR,
Jani.
The following changes since commit 270e3cc5aa382f63ea20b93c3d20162a891dc638:
drm/i915: Fix docbook
+ intel-gfx mailing list
Quoting Zhenyu Wang (2021-04-30 02:58:28)
> On 2021.04.29 20:14:50 +0200, Andreas Friedrich wrote:
> > Hello Joonas,
> >
> > with kernel 5.12 suspend to memory is no longer working on my old
> > Toshiba Tecra A10 notebook.
> >
> > After calling /sbin/pm-suspend the
On piątek, 30 kwietnia 2021 01:01:38 CEST Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix wrong name announced on FB driver switching
> URL : https://patchwork.freedesktop.org/series/89663/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10027_full
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, April 28, 2021 12:26 AM
> To: Gupta, Anshuman
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
> Gaurav, Kumar ; Shankar, Uma
> ; Ceraolo Spurio, Daniele
>
> Subject: Re: [PATCH v3 15/16] drm/i915/pxp: black pixels
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, April 28, 2021 12:25 AM
> To: Gupta, Anshuman
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
> Bommu, Krishnaiah ; Huang Sean Z
> ; Gaurav, Kumar ;
> Ceraolo Spurio, Daniele
> Subject: Re: [PATCH v3 14/16]
> -Original Message-
> From: Ceraolo Spurio, Daniele
> Sent: Thursday, April 29, 2021 2:10 AM
> To: Ville Syrjälä
> Cc: Gupta, Anshuman ; Vivi, Rodrigo
> ; intel-gfx@lists.freedesktop.org; Bommu, Krishnaiah
> ; Gaurav, Kumar
> Subject: Re: [PATCH v3 14/16] drm/i915/pxp: Add plane
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
>
> On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> >
> > On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> > > On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
> > > > On Thu, Apr 29, 2021 at 01:16:04PM -0500,
83 matches
Mail list logo
