On 2021.05.13 09:02:49 -0300, Jason Gunthorpe wrote:
> On Thu, May 13, 2021 at 12:56:47PM +0800, Zhenyu Wang wrote:
> > On 2021.05.12 09:47:39 -0300, Jason Gunthorpe wrote:
> > > On Wed, May 12, 2021 at 10:31:41AM +0800, Zhenyu Wang wrote:
> > >
> > > > > This need to go into the vfio tree in some
Well in my opinion exposing it through fdinfo turned out to be a really
clean approach.
It describes exactly the per file descriptor information we need.
Making that device driver independent is potentially useful as well.
Regards,
Christian.
Am 14.05.21 um 09:22 schrieb Nieto, David M:
[AM
== Series Details ==
Series: series starting with [1/4] drm/i915/display: Nuke has_infoframe
URL : https://patchwork.freedesktop.org/series/90149/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10074_full -> Patchwork_20124_full
=
On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 18:07:04 +0100
> David Woodhouse escreveu:
>
> > On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote:
> > > Such conversion tools - plus some text editor like LibreOffice or
> > > similar - have
>
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Saturday, May 8, 2021 5:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v3 20/48] drm/i915/adl_p: Add cdclk support for
> ADL-P
>
> From: Anusha Srivatsa
>
> ADL-P has 3 possible refclk fr
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Saturday, May 8, 2021 5:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v3 45/48] drm/i915/adl_p: Implement
> Wa_22011091694
>
> From: José Roberto de Souza
>
> Adding a new hook to ADL-P
On Wed, May 12, 2021 at 2:19 AM Ville Syrjälä
wrote:
>
> On Mon, Apr 26, 2021 at 11:24:10PM +0800, Kai-Heng Feng wrote:
> > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> > to discrete GFX after S3. This is not desirable, because userspace will
> > treat connected displa
On Fri, May 07, 2021 at 07:28:01PM -0700, Matt Roper wrote:
> From: Vandita Kulkarni
>
> Update MBUS_CTL register if the 2 mbus can be joined as per the current
> DDB allocation and active pipes, also update hashing mode and pipe
> select bits as per the sequence mentioned in the bspec.
Reviewe
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Saturday, May 8, 2021 5:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v3 46/48] drm/i915/display/adl_p: Implement
> Wa_22011320316
>
> From: José Roberto de Souza
>
> Implementation deta
On 06/05/2021 20:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point in the
upstreaming plan covered in the following RFC [1].
At a very high level the GuC is a piece of firmware which sits between
the i915 and the GPU. It offloads some of the scheduling of co
[AMD Official Use Only - Internal Distribution Only]
We had entertained the idea of exposing the processes as sysfs nodes as you
proposed, but we had concerns about exposing process info in there, especially
since /proc already exists for that purpose.
I think if you were to follow that approac
Em Wed, 12 May 2021 18:07:04 +0100
David Woodhouse escreveu:
> On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote:
> > Such conversion tools - plus some text editor like LibreOffice or similar
> > - have
> > a set of rules that turns some typed ASCII characters into UTF-8
> > alte
While working on a drm driver that doesn't need the i2c algobit stuff I
noticed that DRM selects this code even tough only 8 drivers actually use
it. While also only some drivers use i2c, keep the select for I2C for the
next cleanup patch. Still prepare this already by also selecting I2C for
the in
> On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote:
>> I do use a lot of UTF-8 here, as I type texts in Portuguese, but I rely
>> on the US-intl keyboard settings, that allow me to type as "'a" for á.
>> However, there's no shortcut for non-Latin UTF-codes, as far as I know.
>>
>> So,
Hi
Am 14.05.21 um 03:53 schrieb Stephen Rothwell:
Hi all,
On Fri, 30 Apr 2021 08:23:21 +1000 Stephen Rothwell
wrote:
On Thu, 18 Mar 2021 12:52:41 +1100 Stephen Rothwell
wrote:
On Wed, 17 Mar 2021 14:08:24 +1100 Stephen Rothwell
wrote:
Today's linux-next merge of the drm-intel tree g
From: Ville Syrjälä
Fix some remaining issues around plane updates vs. CxSR on
gmch platforms. Also throw in a few watermark fixes/cleanups,
and finally flip on atomic for g4x since everything is ready.
Ville Syrjälä (14):
drm/i915: s/crtc_state/new_crtc_state/ etc.
drm/i915: Fix g4x cxsr en
From: Ville Syrjälä
intel_plane_atomic_calc_changes() deals with both the old and
new crtc/plane states. Make the variable names reflect that
more clearly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 38 ++--
1 file changed, 19 insertions(+),
From: Ville Syrjälä
If HPLL watermarks are already enabled, let's not mark them as
disabled by forgetting to bump 'level' before we call
g4x_raw_plane_wm_set().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff -
From: Ville Syrjälä
The intention was to check whether the primary plane is enabled
without any sprites planes being enabled. Instead we ended up checking
whether just any one of the planes is enabled. g4x isn't vlv/chv and
cxsr only works with the primary plane. Fix the check to examine the
bitm
From: Ville Syrjälä
We can simplify the g4x watermark sanitation by reusing the
second half of g4x_compute_pipe_wm() to convert the sanitized
raw watermarks into the proper form to be used as the
optimal/intermediate watermarks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c
From: Ville Syrjälä
Let's not forget to mark the unused watermark levels as invalid
after the readout. The vlv/chv codepath has this but the g4x
didn't for some reason.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/driver
From: Ville Syrjälä
On g4x/vlv/chv the hardware seems incapable of changing the pixel
format, rotation, or YUV->RGB CSC matrix while in CxSR.
Additionally on VLV/CHV the sprites seem incapable of tiling
changes while in CxSR. On g4x CxSR is not even possible with
the sprite enabled. Curiously th
From: Ville Syrjälä
Like most other plane control register bits, the pipe gamma
enable bit is also blocked by CxSR. So make sure we kick the
machine out of CxSR before trying to change that bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 4
1 file change
From: Ville Syrjälä
We can simplify the vlv watermark sanitation by reusing the
second half of vlv_compute_pipe_wm() to convert the sanitized
raw watermarks into the proper form to be used as the
optimal/intermediate watermarks.
Also to be consistent with normal watermark computation the sanitiz
From: Ville Syrjälä
Be consistent in that active_planes bitmask fits in a u8.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2fb49
From: Ville Syrjälä
Split g4x_compute_pipe_wm() into two halves. The first half computes
the new raw watermarks, and the second half munges those up into real
watermarks for the particular pipe.
We can reuse the second half for watermark sanitation as well.
Signed-off-by: Ville Syrjälä
---
dr
From: Ville Syrjälä
Split vlv_compute_pipe_wm() into two halves. The first half computes
the new raw watermarks, and the second half munges those up into real
watermarks for the particular pipe.
We can reuse the second half for watermark sanitation as well.
Signed-off-by: Ville Syrjälä
---
dr
From: Ville Syrjälä
The w/a database lists this for both ctg and elk. So let's apply it to
elk as well. And add the w/a name.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
From: Ville Syrjälä
The watermark code for ctg/elk has been atomic ready for a long time
so let's just flip the switch now that some of the last CxSR issues
have been sorted out (which granted was a problem for vlv/chv as well
despite them already having atomic enabled by default).
Signed-off-by
From: Ville Syrjälä
We've excluded gmch platforms from writing the final watermarks
for any disabled pipe. IIRC the reason was perhaps some lingering
issue with the watermark merging across the pipes. But I can't
really see any reason for this anymore, so let's unify this behaviour.
The main bene
On Thu, May 13, 2021 at 01:07:56PM +0100, Matthew Auld wrote:
> From: Chris Wilson
>
> When instantiating a tiled object on an L-shaped memory machine, we mark
> the object as unshrinkable to prevent the shrinker from trying to swap
> out the pages. We have to do this as we do not know the swizzl
On Fri, 2021-05-07 at 14:42 -0400, Rodrigo Vivi wrote:
> >
> On Fri, Apr 30, 2021 at 03:55:28PM +0300, Ville Syrjälä wrote:
> > On Fri, Apr 30, 2021 at 07:12:53AM +, Gupta, Anshuman wrote:
> > >
> > > > -Original Message-
> > > > From: Ville Syrjälä
> > > > Sent: Wednesday, April 28,
On 14/05/2021 09:04, Christian König wrote:
Well in my opinion exposing it through fdinfo turned out to be a really
clean approach.
It describes exactly the per file descriptor information we need.
Yeah fdinfo certainly is mostly simple and neat.
I say mostly because main problem I see with
On Fri, May 07, 2021 at 07:27:36PM -0700, Matt Roper wrote:
> The DDI naming template for display version 12 went A-C, TC1-TC6. With
> XE_LPD, that naming scheme for DDI's has now changed to A-E, TC1-TC4.
>
> The XE_LPD design keeps the register offsets and bitfields relating to
> the TC outputs
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but one per open drm fd.
Yes, we discussed this as well, but then rejected the approach.
To have useful information related to the open d
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but one per open drm fd.
Yes, we discussed this as well, but then rejected the approach.
To
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but one per open drm fd.
Yes, we discussed thi
== Series Details ==
Series: drm: Only select I2C_ALGOBIT for drivers that actually need it
URL : https://patchwork.freedesktop.org/series/90163/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10082 -> Patchwork_20125
Summar
On 14/05/2021 15:56, Christian König wrote:
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but
== Series Details ==
Series: drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups
URL : https://patchwork.freedesktop.org/series/90164/
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/i9
Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
On 14/05/2021 15:56, Christian König wrote:
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of
exposing process info in there. To clarify, my patch
== Series Details ==
Series: drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups
URL : https://patchwork.freedesktop.org/series/90164/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10082 -> Patchwork_20126
Summary
---
**SUC
From: Animesh Manna
Respective bit for master or slave to be set for uncompressed
bigjoiner in dss_ctl1 register.
Cc: Manasi Navare
Signed-off-by: Animesh Manna
Signed-off-by: Clinton Taylor
Signed-off-by: Matt Roper
Reviewed-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display
From: Anusha Srivatsa
ADL-P has 3 possible refclk frequencies: 19.2MHz,
24MHz and 38.4MHz
While we're at it, remove the drm_WARNs. They've never actually helped
us catch any problems, but it's very easy to forget to update them
properly for new platforms.
BSpec: 55409, 49208
Cc: Matt Roper
Cc
From: José Roberto de Souza
This will allow proper DDI initialization based on vbt information.
Cc: Uma Shankar
Signed-off-by: José Roberto de Souza
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_bios.c | 18 +-
1 file changed,
From: José Roberto de Souza
Implementation details are in the HSD 22011320316, requiring CD clock
to be at least 307MHz to make DC states to work.
Cc: Matt Roper
Cc: Anusha Srivatsa
Signed-off-by: José Roberto de Souza
Signed-off-by: Clinton Taylor
Signed-off-by: Matt Roper
Reviewed-by: Mik
From: José Roberto de Souza
Buffer compression is not usable in A stepping.
Cc: Matt Roper
Cc: Anusha Srivatsa
Cc: Clinton A Taylor
Cc: Juha-Pekka Heikkilä
Signed-off-by: José Roberto de Souza
Signed-off-by: Clinton Taylor
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
---
.../d
ADL-P further extends the bits in PLANE_WM that represent blocks and
lines; we need to extend our masks accordingly. Since these bits are
reserved and MBZ on earlier platforms, it's safe to use the larger
bitmask on all platforms.
Bspec: 50419
Cc: Matt Atwood
Signed-off-by: Matt Roper
Signed-of
From: José Roberto de Souza
Adding a new hook to ADL-P just to avoid another platform check in
gen12lp_init_clock_gating() but also open to it.
BSpec: 54369
Cc: Matt Roper
Cc: Anusha Srivatsa
Signed-off-by: José Roberto de Souza
Signed-off-by: Clinton Taylor
Signed-off-by: Matt Roper
Review
From: Vandita Kulkarni
We need slice height to calculate few RC parameters
hence assign slice height first.
Cc: Manasi Navare
Signed-off-by: Vandita Kulkarni
Signed-off-by: Matt Roper
Reviewed-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_dp.c | 8
1 file changed, 4 inse
From: Animesh Manna
For uncompressed big joiner DSC engine will not be used so will avoid
compute config of DSC.
Cc: Manasi Navare
Signed-off-by: Animesh Manna
Signed-off-by: Clinton Taylor
Signed-off-by: Matt Roper
Reviewed-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_dp.c | 8
Animesh Manna (3):
drm/i915/bigjoiner: Mode validation with uncompressed pipe joiner
drm/i915/bigjoiner: Avoid dsc_compute_config for uncompressed
bigjoiner
drm/i915/bigjoiner: atomic commit changes for uncompressed joiner
Anusha Srivatsa (1):
drm/i915/adl_p: Add cdclk support for ADL-
From: José Roberto de Souza
This will allow us to better implement workarounds.
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
Signed-off-by: Jani Nikula
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/in
From: Mika Kahola
Disable loadgen sharing for DP link rate 1.62 GHz and HDMI 5.94 GHz.
For all other modes, we can enable loadgen sharing feature.
BSpec: 55359
Cc: Imre Deak
Signed-off-by: Mika Kahola
Signed-off-by: Clinton Taylor
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
---
The DDI naming template for display version 12 went A-C, TC1-TC6. With
XE_LPD, that naming scheme for DDI's has now changed to A-E, TC1-TC4.
The XE_LPD design keeps the register offsets and bitfields relating to
the TC outputs in the same location they were previously. The new "D"
and "E" output
From: Ville Syrjälä
Move intel_modeset_all_pipes() to a central place so that we can
use it elsewhere as well. No functional changes.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
Signed-off-by: Clinton Taylor
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/dr
From: Vandita Kulkarni
Support compression BPPs from bpc to uncompressed BPP -1.
So far we have 8,10,12 as valid compressed BPPS now the
support is extended.
Cc: Manasi Navare
Signed-off-by: Vandita Kulkarni
Signed-off-by: Matt Roper
Reviewed-by: Manasi Navare
---
drivers/gpu/drm/i915/displ
XE_LPD continues to use the same "skylake-style" watermark
programming as other recent platforms. The only change to the watermark
calculations compared to Display12 is that XE_LPD now allows a
maximum of 255 lines vs the old limit of 31.
Due to the larger possible lines value, the corresponding
From: José Roberto de Souza
Alderlake P have modular FIA like TGL but it is always modular in all
skus, not like TGL that we had to read a register to check if it is
monolithic or modular.
BSpec: 55480
BSpec: 50572
Cc: Imre Deak
Signed-off-by: José Roberto de Souza
Signed-off-by: Clinton Taylo
From: Animesh Manna
No need for checking dsc flag for uncompressed pipe joiner mode
validation.
Cc: Manasi Navare
Signed-off-by: Animesh Manna
Signed-off-by: Clinton Taylor
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
Reviewed-by: Manasi Navare
---
drivers/gpu/drm/i915/display/i
From: José Roberto de Souza
When DP_PHY_MODE_STATUS_NOT_SAFE is set, it means that display
has the control over the TC phy.
The "not safe" naming is confusing using ownership make it easier
to read also future platforms will have a new register that does the
same job as DP_PHY_MODE_STATUS_NOT_SAF
From: Vandita Kulkarni
Move the platform specific max bpc calculation into
intel_dp_dsc_compute_bpp function
Cc: Manasi Navare
Signed-off-by: Vandita Kulkarni
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dp.c | 20 ++--
1 file
Pulling a few threads together...
On Mon, May 10, 2021 at 1:39 PM Francisco Jerez wrote:
>
> I agree with Martin on this. Given that using GuC currently involves
> making your open-source graphics stack rely on a closed-source
> cryptographically-protected blob in order to submit commands to the
On Fri, May 14, 2021 at 6:12 AM Tvrtko Ursulin
wrote:
>
> On 06/05/2021 20:13, Matthew Brost wrote:
> > Basic GuC submission support. This is the first bullet point in the
> > upstreaming plan covered in the following RFC [1].
> >
> > At a very high level the GuC is a piece of firmware which sits
== Series Details ==
Series: Another batch of reviewed XeLPD / ADL-P patches
URL : https://patchwork.freedesktop.org/series/90169/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dc16ea52587b drm/i915/xelpd: Handle new location of outputs D and E
314d49aa2d02 drm/i915/xelpd: Incr
== Series Details ==
Series: Another batch of reviewed XeLPD / ADL-P patches
URL : https://patchwork.freedesktop.org/series/90169/
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
Hello.
On Fri, May 14, 2021 at 10:24:26AM +0200, Thomas Stein wrote:
> After upgrading to linux 5.12 the display on my X1 Carbon Gen 2 starts to
> flicker. Well actually it seems to turn off and on again and again. Here a
> link to a video a person posted who has the same issue as me obviousely.
On Fri, May 14, 2021 at 12:11:56PM +0100, Tvrtko Ursulin wrote:
>
> On 06/05/2021 20:13, Matthew Brost wrote:
> > Basic GuC submission support. This is the first bullet point in the
> > upstreaming plan covered in the following RFC [1].
> >
> > At a very high level the GuC is a piece of firmware
On Fri, May 14, 2021 at 11:36:37AM -0500, Jason Ekstrand wrote:
> On Fri, May 14, 2021 at 6:12 AM Tvrtko Ursulin
> wrote:
> >
> > On 06/05/2021 20:13, Matthew Brost wrote:
> > > Basic GuC submission support. This is the first bullet point in the
> > > upstreaming plan covered in the following RFC
== Series Details ==
Series: Another batch of reviewed XeLPD / ADL-P patches
URL : https://patchwork.freedesktop.org/series/90169/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10083 -> Patchwork_20127
Summary
---
**
On Wed, May 12, 2021 at 04:30:46PM +0300, Jani Nikula wrote:
> Follow the usual naming conventions. Also pull HAS_GMCH() check to
> intel_panel_fitting(). No functional changes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
> drivers/gpu/drm/i915/di
On Tue, 2021-05-11 at 19:05 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that we have to tell intel_hdmi_mode_clock_valid() whether
> we're asking about 4:4:4 or 4:2:0 output it can take care of
> the dotclock->TMDS clock conversion.
>
> Cc: Werner Sembach
> Signed-off-by: Ville Sy
On Tue, 2021-05-11 at 19:05 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Extract intel_hdmi_bpc_possible() from intel_hdmi_deep_color_possible()
> so that we can reuse it for mode validation.
>
Reviewed-by: José Roberto de Souza
> Cc: Werner Sembach
> Signed-off-by: Ville Syrjälä
>
On Tue, 2021-05-11 at 19:05 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently HDMI .mode_valid() only checks whether the source can do
> deep color. Let's check whether the sink can do it as well.
>
Reviewed-by: José Roberto de Souza
> Cc: Werner Sembach
> Signed-off-by: Ville
On Tue, 2021-05-11 at 19:05 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We wish intel_hdmi_bpc_possible() to consider whether the sink
> supports HDMI or just DVI when checking whether it'll support
> HDMI deep color or not. This also takes care of the "force DVI"
> property.
Reviewed-
On Tue, 2021-05-11 at 19:05 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's put the platform checks into intel_hdmi_bpc_possible() so that
> it'll confirm both the source and sink capabilities.
Reviewed-by: José Roberto de Souza
>
> Cc: Werner Sembach
> Signed-off-by: Ville Syrjä
On Tue, 2021-05-11 at 19:05 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_hdmi_bpc_possible() will check has_hdmi_sink for us, so no
> need to check it in intel_hdmi_mode_clock_valid() anymore.
Reviewed-by: José Roberto de Souza
>
> Cc: Werner Sembach
> Signed-off-by: Ville Syr
On Fri, May 14, 2021 at 05:28:40PM +, Souza, Jose wrote:
> On Tue, 2021-05-11 at 19:05 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Now that we have to tell intel_hdmi_mode_clock_valid() whether
> > we're asking about 4:4:4 or 4:2:0 output it can take care of
> > the dotclock->
On Fri, 2021-05-14 at 20:36 +0300, Ville Syrjälä wrote:
> On Fri, May 14, 2021 at 05:28:40PM +, Souza, Jose wrote:
> > On Tue, 2021-05-11 at 19:05 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Now that we have to tell intel_hdmi_mode_clock_valid() whether
> > > we're askin
On Tue, May 4, 2021 at 3:47 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:23AM -0500, Jason Ekstrand wrote:
> > 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_ALL
On Tue, May 4, 2021 at 3:50 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:27AM -0500, Jason Ekstrand wrote:
> > 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_PA
This series:
* Cleans up i915's DPCD backlight code a little bit
* Extracts i915's DPCD backlight code into a set of shared DRM helpers
* Starts using those helpers in nouveau to add support to nouveau for
DPCD backlight control
v2 series-wide changes:
* Rebase
v3 series-wide changes:
* Split up
This is kind of an annoying aspect of DRM's DP helpers:
drm_dp_dpcd_readb/writeb() return the size of bytes read/written on
success, thus we want to check against that instead of checking if the
return value is less than 0.
I'll probably be fixing this in the near future once I start doing DP work
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
thi
Get rid of the extraneous switch case in here, and just open code
edp_backlight_mode as we only ever use it once.
v4:
* Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not
DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
..
Also, stop printing the DPCD register that failed, and just describe it
instead. Saves us from having to look up each register offset when reading
through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
us that anyway).
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.
No functional changes, just move set_vesa_backlight_enable() closer to it's
only caller: intel_dp_aux_vesa_enable_backlight().
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 54 +--
1 file changed, 27 insertions(+), 27 del
This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of),
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control bit
Since we're about to be moving this code into shared DRM helpers, we might
as well start to cache certain backlight capabilities that can be
determined from the EDP DPCD, and are likely to be relevant to the majority
of drivers using said helpers. The main purpose of this is just to prevent
every d
If we can't read DP_EDP_PWMGEN_BIT_COUNT in
intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
defined in the VBT, we'll keep going in the function until we inevitably
fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in
doing this, so just return early.
On Tue, May 4, 2021 at 3:56 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:31AM -0500, Jason Ekstrand wrote:
> > 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.
On Tue, May 4, 2021 at 11:17 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:38AM -0500, Jason Ekstrand wrote:
> > Since free_engines works for partially constructed engine sets, we can
> > use the usual goto pattern.
> >
> > Signed-off-by: Jason Ekstrand
>
> I guess subsequent patches
== Series Details ==
Series: drm: Extract DPCD backlight helpers from i915, add support in nouveau
(rev8)
URL : https://patchwork.freedesktop.org/series/84754/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
268e6a95dfed drm/i915/dpcd_bl: Remove redundant AUX backlight frequency
== Series Details ==
Series: drm: Extract DPCD backlight helpers from i915, add support in nouveau
(rev8)
URL : https://patchwork.freedesktop.org/series/84754/
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: drm: Extract DPCD backlight helpers from i915, add support in nouveau
(rev8)
URL : https://patchwork.freedesktop.org/series/84754/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10083 -> Patchwork_20128
=
On Tue, May 4, 2021 at 3:33 PM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:40AM -0500, Jason Ekstrand wrote:
> > 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 setpa
On Wed, May 12, 2021 at 10:34:59AM +0200, Daniel Vetter wrote:
> On Tue, May 11, 2021 at 11:44:28AM -0700, Matthew Brost wrote:
> > On Tue, May 11, 2021 at 05:11:44PM +0200, Daniel Vetter wrote:
> > > On Thu, May 06, 2021 at 10:30:48AM -0700, Matthew Brost wrote:
> > > > i915_drm.h updates for 'set
== Series Details ==
Series: drm: Only select I2C_ALGOBIT for drivers that actually need it
URL : https://patchwork.freedesktop.org/series/90163/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10082_full -> Patchwork_20125_full
==
== Series Details ==
Series: drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups
URL : https://patchwork.freedesktop.org/series/90164/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10082_full -> Patchwork_20126_full
Summary
--
1 - 100 of 157 matches
Mail list logo
