for doing that and hook them up in various drivers.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
drivers/gpu/drm/display/drm_dp_mst_topology.c
the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.
So, let's just move this code into drm_dp_atomic_release_time_slots() and
stop open coding it.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc
or allocate timeslots
on. As well, add some helpers for:
* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre D
is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |
is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |
d me an email to
x...@codeweavers.com, adding on CC the X.org board (board
at foundation.x.org).
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
https://twitter.com/XOrgDevConf
Best regards,
Lyude Paul, on behalf of X.org
u8 reserved1:5;
> > u16 dpst;
> > u16 psr;
> > u16 drrs;
> > @@ -876,6 +907,9 @@ struct bdb_lfp_power {
> > struct aggressiveness_profile_entry aggressiveness[16];
> > u16 hobl; /* 232+ */
> > u16 vrr_feature_
ave an internal panel, but no nv_backlight,
> + * try registering an ACPI video backlight device instead.
> + */
> + if (ret == 0)
> + acpi_video_register_backlight();
Assuming we don't need to return the value of acpi_video_register_backlight()
here:
Reviewed-by: Lyude Paul
> +
> return ret;
> }
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Reviewed-by: Lyude Paul
Also, ack on this being pushed to drm-misc, along with any other patches I r-b
On Tue, 2022-05-17 at 17:23 +0200, Hans de Goede wrote:
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight
there generally will be a
bit of Q with organizers.
And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.
Best regards,
Lyude Paul
On behalf of X.org
oard (board
at foundation.x.org).
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
https://twitter.com/XOrgDevConf
Best regards,
Lyude Paul, on behalf of X.org
that Emma Anholt, Alyssa Rosenzweig, Mark Filion and
Ricardo Garcia were elected for two year terms.
The old full board is: Emma Anholt, Samuel Iglesias Gonsálvez, Mark
Filion, Manasi D Navare, Keith Packard, Lyude Paul, Daniel Vetter, Harry
Wentland
The new full board is: Emma Anholt, Samuel
Reviewed-by: Lyude Paul
On Wed, 2022-04-13 at 11:28 +0300, Jouni Högander wrote:
> We have now seen panel (XMG Core 15 e21 laptop) advertizing support
> for Intel proprietary eDP backlight control via DPCD registers, but
> actually working only with legacy pwm control.
>
> This p
On Wed, 2022-04-13 at 08:31 +, Hogander, Jouni wrote:
> Hello Lyude,
>
> See my respose below.
>
> On Tue, 2022-04-12 at 13:50 -0400, Lyude Paul wrote:
> > On Tue, 2022-04-12 at 08:25 +0300, Jouni Högander wrote:
> > > We have now seen panel (XMG Core 15
ck for possible HDR static metadata and
> does detection from DPCD registers only if this data block exists.
>
> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface
> (only SDR for now)")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/
begins.
Lyude Paul, on behalf of the X.Org elections committee
in the
upcoming election is 31 March 2022 at 23:59 UTC.
If you are interested in joining the X.Org Foundation or in renewing
your membership, please visit the membership system site at:
https://members.x.org/
Lyude Paul, on behalf of the X.Org elections committee
were Lyude Paul,
Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will
continue to serve until their term ends in 2023. Current directors whose term
expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark
Filion.
A director is expected to participate
nnector
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index e30e698aa684..442dbd0ed201 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -151,8 +151,9 @@ static int intel_dp_mst_compute_config(struct
> > intel_encoder *encoder,
> > intel_conn_state->force_audio == HDMI_AUDIO_ON;
> >
> > /*
> > - * for MST we always configure max link bw - the spec doesn't
> > - * seem to suggest we should do otherwise.
> > + * For MST we always configure max link bw - the spec doesn't seem
> > to
> > + * suggest we should do otherwise. The values may be reduced due
> > to link
> > + * training failures, however.
> > */
> > limits.min_rate =
> > limits.max_rate = intel_dp_max_link_rate(intel_dp);
> > --
> > 2.30.2
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
will serve as directors for two year
terms.
The directors who received two year terms starting in 2021 were Lyude Paul,
Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will
continue to serve until their term ends in 2023. Current directors whose term
expires in 2022 are Emma Anholt
JFYI I've been running the patch on my laptop for about a day now, flickering
is totally gone and also I'm a bit astonished at the power savings!
Tested-by: Lyude Paul
On Thu, 2022-02-24 at 15:02 -0500, Lyude Paul wrote:
> Also - I realized this is missing an appropriate Fixes:
update seems to
> > fix screen flickering.
> >
> > Also make code more clear by setting PSR2_MAN_TRK_CTL_ENABLE
> > only if not on ADLP as this bit doesn't exist in ADLP.
>
> Bit exist but has another name.
>
> >
> > Bspec: 49274
> >
> > v2: Fix Mihai Harp
R(val) REG_FIELD_PREP(ADLP_PS
> R2_MAN_TRK_CTL_SU_REGION_START_ADDR_MASK, val)
> #define
> ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK REG_GENMASK(12, 0)
> #define
> ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(val) REG_FIELD_PREP(ADLP_PS
> R2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK, val)
> +#define ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE REG_BIT(31)
> #define ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAMEREG_BIT(14)
> #define ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME REG_BIT(13)
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
of directors elected from the membership. Each year, an
election is held to bring the total number of directors to eight. The four
members receiving the highest vote totals will serve as directors for two year
terms.
The directors who received two year terms starting in 2021 were Lyude Paul,
Samuel
/Elections/2022/
Lyude Paul,
On behalf of the X.Org elections committee
Opened the issue at https://gitlab.freedesktop.org/drm/intel/-/issues/5077 ,
included dmesg + video. Feel free to let me know if you need any more info, or
need me to try any patches
On Tue, 2022-02-08 at 13:06 +, Souza, Jose wrote:
> On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wr
On Tue, 2022-02-08 at 13:06 +, Souza, Jose wrote:
> On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> > As we've unfortunately started to come to expect from PSR on Intel
> > platforms, PSR2 selective fetch is not at all ready to be enabled on
> > Tigerlake as
-by: Lyude Paul
Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by default")
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Cc: José Roberto de Souza
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: # v5.16+
---
drivers/gpu/drm/i915/display/intel_
/Elections/2022/
Lyude Paul,
On behalf of the X.Org elections committee
Acked-by: Lyude Paul
BTW - I made a ton of progress last week on getting all of this stuff moved
into the atomic state :), mainly just trying to get amd hooked up with this
now (and need to rebase):
https://gitlab.freedesktop.org/lyudess/linux/-/commits/wip/mst-atomic-only-v1
So we soon won't
Acked-by: Lyude Paul
On Wed, 2021-12-15 at 11:43 +0100, Thomas Zimmermann wrote:
> Move DisplayPort functions into a separate module to reduce the size
> of the KMS helpers. Select DRM_DP_HELPER for all users of the code. To
> avoid naming conflicts, rename drm_dp_helper.c to
delays into intel_pps
Signed-off-by: Lyude Paul
Reviewed-by: Jani Nikula
Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only
SDR for now)")
Cc: Ville Syrjälä
Cc: # v5.12+
---
drivers/gpu/drm/i915/display/intel_display_types.h| 3 +++
drivers/gpu/drm/i9
On Tue, 2021-11-30 at 12:36 +0200, Jani Nikula wrote:
> On Mon, 29 Nov 2021, Lyude Paul wrote:
> > While working on supporting the Intel HDR backlight interface, I noticed
> > that there's a couple of laptops that will very rarely manage to boot up
> > without detectin
since that
timestamp right before we interact with the backlight) in order to avoid
waiting any longer then we need to. As well, this also avoids us performing
this delay on systems where we don't end up using the HDR backlight
interface.
V2:
* Move panel delays into intel_pps
Signed-off-by: Lyude
Reviewed-by: Lyude Paul
On Sun, 2021-11-21 at 12:00 +0100, Hans de Goede wrote:
> At least the Bay Trail LPSS PWM controller used with DSI panels on many
> Bay Trail tablets seems to leave the PWM pin in whatever state it was
> (high or low) ATM that the PWM gets disabled. Combined
On Mon, 2021-11-15 at 12:53 +0200, Jani Nikula wrote:
> On Fri, 12 Nov 2021, Lyude Paul wrote:
> > While working on supporting the Intel HDR backlight interface, I noticed
> > that there's a couple of laptops that will very rarely manage to boot up
> > without detectin
since that
timestamp right before we interact with the backlight) in order to avoid
waiting any longer then we need to. As well, this also avoids us performing
this delay on systems where we don't end up using the HDR backlight
interface.
Signed-off-by: Lyude Paul
Fixes: 4a8d79901d5b ("drm/i9
forgive me and we can move past this~
Signed-off-by: Lyude Paul
Acked-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.
v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps
Signed-off-by: Lyude Paul
Reviewed-by: Doug Anderson
Cc: Rajeev Nandan
(but not all) of the issues seen with DPCD
backlight support on fi-bdw-samus
v5:
* Just avoid reading back DPCD register - Doug Anderson
Signed-off-by: Lyude Paul
Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP backlight code into DRM
helpers")
---
drivers/gpu/drm/drm_dp_hel
Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.
Reviewed-by: Karol Herbst
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_backlight.c
() in
intel_dp_aux_vesa_enable_backlight() - vsyrjala
Signed-off-by: Lyude Paul
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM
enable/disable")
Reviewed-by: Ville Syrjälä
Cc: # v5.12+
---
.../drm/i915/display/intel_dp_aux_backli
about probing backlights in i915
for the most part, let's update some of the comments around that as
well!
Lyude Paul (5):
drm/i915: Add support for panels with VESA backlights with PWM
enable/disable
drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux
enable/brightness
JFYI - the wrapping was because of evolution, sorry about that. Going to make
sure that gets fixed the next time I have to send out a topic branch
On Fri, 2021-10-29 at 13:35 +0300, Jani Nikula wrote:
> On Fri, 29 Oct 2021, Jani Nikula wrote:
> > On Wed, 27 Oct 2021, Lyude Pa
On Thu, 2021-10-28 at 11:27 -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Oct 26, 2021 at 3:09 PM Lyude Paul wrote:
> >
> > As it turns out, apparently some machines will actually leave additional
> > backlight functionality like dynamic backlight control on before
/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/radeon/radeon_dp_mst.c | 4 +-
include/drm/drm_dp_mst_helper.h | 5 +-
13 files changed, 425 insertions(+), 16 deletions(-)
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
This was for airlied to pull into drm-next
On Wed, 2021-10-27 at 09:18 +0200, Maxime Ripard wrote:
> Hi Lyude,
>
> On Mon, Oct 25, 2021 at 09:30:14PM -0400, Lyude Paul wrote:
> > topic/amdgpu-dp2.0-mst-2021-10-25:
> > UAPI Changes:
> > Nope!
>
forgive me and we can move past this~
Signed-off-by: Lyude Paul
Acked-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.
v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps
Signed-off-by: Lyude Paul
Reviewed-by: Doug Anderson
Cc: Rajeev Nandan
Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
1 file changed
behavior when adjusting the backlight.
So, let's fix this by ensuring we only keep supported features enabled for
panel backlights - which should fix some of the issues we were seeing from
this on fi-bdw-samus.
Signed-off-by: Lyude Paul
Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP back
() in
intel_dp_aux_vesa_enable_backlight() - vsyrjala
Signed-off-by: Lyude Paul
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM
enable/disable")
Cc: # v5.12+
---
.../drm/i915/display/intel_dp_aux_backlight.c | 27 ++---
on by mistake which certainly have the potential to cause
problems.
UPDATE: this didn't fix the problem, but this changed the symptoms was
definitely still a bug either way.
Changes (v2):
* Fixup docs
* Add patch to stop us from breaking nouveau
Lyude Paul (5):
drm/i915: Add support for panels
me years ago) Lyude took over the
> actual vblank worker implementation, mostly rewrote it I think,
> and landed it for use in nouveau. So now I'm just left with the
> easy task of using it for i915 gamma LUT updates. And so here
> we are.
>
> CC: Lyude Paul
>
> Ville Syrj
topic/amdgpu-dp2.0-mst-2021-10-25:
UAPI Changes:
Nope!
Cross-subsystem Changes:
drm_dp_update_payload_part1() takes a new argument for specifying what the
VCPI slot start is
Core Changes:
Make the DP MST helpers aware of the current starting VCPI slot/VCPI total
slot count...
Driver Changes:
nfo
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
[v5 nitpicks]
Reviewed-by: Lyude Paul
Signed-off-by: Lyude Paul
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 36 ---
drivers/gpu/drm/i915/display/intel_dp_ms
nfo
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
[v5 nitpicks]
Reviewed-by: Lyude Paul
Signed-off-by: Lyude Paul
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 36 ---
drivers/gpu/drm/i915/display/intel_dp_ms
On Tue, 2021-10-19 at 21:09 +0300, Ville Syrjälä wrote:
> On Tue, Oct 05, 2021 at 10:40:14PM -0400, Lyude Paul wrote:
> > This simply adds proper support for panel backlights that can be
> > controlled
> > via VESA's backlight control protocol, but which also require that we
&
g format on mst_state 0x%p\n",
> + (link_ecoding_cap == DP_CAP_ANSI_128B132B) ?
> "128b/132b":"8b/10b", mst_state->mgr);
> +}
> +EXPORT_SYMBOL(drm_dp_mst_update_slots);
Some typos (s/ecoding/encoding), and also this should be reformatted
Reviewed-by: Lyude Paul
On Wed, 2021-10-20 at 10:16 -0400, Bhawanpreet Lakha wrote:
> This code path is used during commit, and we dont expect things to fail
> during the commit stage, so remove this.
>
> Signed-off-by: Bhawanpreet Lakha
> ---
> drivers/gpu/drm/drm_dp_
; Warnings * igt@i915_pm_rc6_residency@rc6-idle:shard-iclb: WARN ([i915#2684])
> -> WARN
>([i915#1804] / [i915#2684])
> * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-1:shard-iclb: SKIP
>([i915#2920]) -> SKIP ([i915#658]) +3 similar issues
> * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-2:shard-iclb: SKIP
>([i915#658]) -> SKIP ([i915#2920]) +1 similar issue
> * igt@runner@aborted:shard-kbl: (FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL)
>([i915#1436] / [i915#180] / [i915#1814] / [i915#3002] / [i915#3363]) ->
>(FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL) ([i915#180] /
>[i915#1814] / [i915#3002] / [i915#3363] / [i915#92])shard-apl: (FAIL, FAIL,
>FAIL) ([fdo#109271] / [i915#1814] / [i915#3002] / [i915#3363]) -> (FAIL,
>FAIL, FAIL) ([i915#180] / [i915#1814] / [i915#3002] / [i915#3363])shard-
>skl: ([FAIL][147], [FAIL][148], [FAIL][149], [FAIL][150]) ([i915#1436] /
>[i915#2029] / [i915#3002] / [i915#3363]) -> ([FAIL][151], [FAIL][152]) ([i
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
On Wed, 2021-10-06 at 18:30 +0200, Karol Herbst wrote:
> On Wed, Oct 6, 2021 at 4:41 AM Lyude Paul wrote:
> >
> > Since we don't support hybrid AUX/PWM backlights in nouveau right now,
> > let's add some explicit checks so that we don't break nouveau once
forgive me and we can move past this~
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.
v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps
Signed-off-by: Lyude Paul
Cc: Rajeev Nandan
Cc: Doug Anderson
Cc
behavior when adjusting the backlight.
So, let's fix this by ensuring we only keep supported features enabled for
panel backlights - which should fix some of the issues we were seeing from
this on fi-bdw-samus.
Signed-off-by: Lyude Paul
Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP back
Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
1 file changed
that were broken by not having this enabled.
For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.
Signed-off-by: Lyude Paul
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes
on by mistake which certainly have the potential to cause
problems.
Changes (v2):
* Fixup docs
* Add patch to stop us from breaking nouveau
Lyude Paul (5):
drm/i915: Add support for panels with VESA backlights with PWM
enable/disable
drm/nouveau/kms/nv50-: Explicitly check DPCD backlights
On Sat, 2021-10-02 at 11:14 +0200, Hans de Goede wrote:
> Hi Lyude,
>
> On 10/2/21 12:53 AM, Lyude Paul wrote:
> > When I originally moved all of the VESA backlight code in i915 into DRM
> > helpers, one of the things I didn't have the hardware or time for
> > tes
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.
v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps
Signed-off-by: Lyude Paul
Cc: Rajeev Nandan
Cc: Doug Anderson
Cc
forgive me and we can move past this~
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display
that were broken by not having this enabled.
For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.
Signed-off-by: Lyude Paul
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes
Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
1 file changed
about probing backlights in i915
for the most part, let's update some of the comments around that as
well!
Changes:
* Fixup docs
* Add patch to stop us from breaking nouveau
Lyude Paul (4):
drm/i915: Add support for panels with VESA backlights with PWM
enable/disable
drm/nouveau/kms/nv50
gt; > when the driver doesn't
> > + * support %DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM
>
> Why is aux_enable always false if it doesn't support
> DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM? It doesn't seem like the code
> enforces this and I'm not sure why it would. Am I confused?
This was mainly just to keep the behavior identical for drivers that
didn't support controlling backlights like this, but re: the response I
wrote up above I think we can just totally drop the caps.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
forgive me and we can move past this~
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display
it into PWM-only mode on some of
my laptops.
Signed-off-by: Lyude Paul
Cc: Rajeev Nandan
Cc: Doug Anderson
Cc: Satadru Pramanik
---
drivers/gpu/drm/drm_dp_helper.c | 102 ++
.../drm/i915/display/intel_dp_aux_backlight.c | 51 ++---
drivers/gpu/drm/nouveau
that were broken by not having this enabled.
For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.
Signed-off-by: Lyude Paul
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes
about probing backlights in i915
for the most part, let's update some of the comments around that as
well!
Lyude Paul (3):
drm/i915: Add support for panels with VESA backlights with PWM
enable/disable
drm/dp, drm/i915: Add support for VESA backlights using PWM for
brightness control
self in your reply to the coverletter I will
> push out the rest of the series to drm-misc-next while we figure this
> out. Assuming Lyude is happy with the answers which I gave to her
> remarks about some of the other patches.
I am, btw!
>
> Regards,
>
> Hans
>
--
Cheers
On Thu, 2021-09-16 at 11:06 +0200, Hans de Goede wrote:
> Hi,
>
> On 9/15/21 10:26 PM, Lyude Paul wrote:
> > On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> > > Add support for privacy-screen consumers to register a notifier to
> > > be notified of ext
OK! Looked over all of these patches. Patches 2 and 4 have some comments that
should be addressed, but otherwise this series is:
Reviewed-by: Lyude Paul
Let me know when/if you need help pushing this upstream
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> Hi all,
>
gt; + /*
> + * We do not handle -EPROBE_DEFER further into the probe process, so
> + * check if we have a laptop-panel privacy-screen for which the
> driver
> + * has not loaded yet here.
> + */
> + privacy_screen = drm_privacy_screen_get(>dev, NULL);
> + if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -
> EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> err = i915_driver_probe(pdev, ent);
> + drm_privacy_screen_put(privacy_screen);
> if (err)
> return err;
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
+
> + return res;
> }
>
> static struct ibm_struct lcdshadow_driver_data = {
> .name = "lcdshadow",
> + .exit = lcdshadow_exit,
> .resume = lcdshadow_resume,
> .read = lcdshadow_read,
> .write = lcdshadow_write,
> @@ -10717,6 +10750,14 @@ static void tpacpi_driver_event(const unsigned int
> hkey_event)
> if (!atomic_add_unless(_ignore_event, -1, 0))
> dytc_profile_refresh();
> }
> +
> + if (lcdshadow_dev && hkey_event == TP_HKEY_EV_PRIVACYGUARD_TOGGLE) {
> + mutex_lock(_dev->lock);
> + lcdshadow_get_hw_state(lcdshadow_dev);
> + mutex_unlock(_dev->lock);
> +
> + drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
> + }
> }
>
> static void hotkey_driver_event(const unsigned int scancode)
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
n_driver.h
> @@ -54,6 +54,8 @@ struct drm_privacy_screen {
> struct mutex lock;
> /** @list: privacy-screen devices list list-entry. */
> struct list_head list;
> + /** @notifier_head: privacy-screen notifier head. */
> + struct blocking_notifier_head not
*/
> + enum drm_privacy_screen_status sw_state;
> + /**
> + * @hw_state: The privacy-screen's hardware state, see
> + * :ref:`Standard Connector
> Properties`
> + * for more info.
> + */
> + enum drm_privacy_screen_status hw_state;
> +};
> +
> +struct drm_privacy_screen *drm_privacy_screen_register(
> + struct device *parent, const struct drm_privacy_screen_ops *ops);
> +void drm_privacy_screen_unregister(struct drm_privacy_screen *priv);
> +
> +#endif
> diff --git a/include/drm/drm_privacy_screen_machine.h
> b/include/drm/drm_privacy_screen_machine.h
> new file mode 100644
> index ..aaa0d38cce92
> --- /dev/null
> +++ b/include/drm/drm_privacy_screen_machine.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright (C) 2020 Red Hat, Inc.
> + *
> + * Authors:
> + * Hans de Goede
> + */
> +
> +#ifndef __DRM_PRIVACY_SCREEN_MACHINE_H__
> +#define __DRM_PRIVACY_SCREEN_MACHINE_H__
> +
> +#include
> +
> +/**
> + * struct drm_privacy_screen_lookup - static privacy-screen lookup list
> entry
> + *
> + * Used for the static lookup-list for mapping privacy-screen consumer
> + * dev-connector pairs to a privacy-screen provider.
> + */
> +struct drm_privacy_screen_lookup {
> + /** @list: Lookup list list-entry. */
> + struct list_head list;
> + /** @dev_id: Consumer device name or NULL to match all devices. */
> + const char *dev_id;
> + /** @con_id: Consumer connector name or NULL to match all
> connectors. */
I think this patch mostly looks good, the one part that I'm a little confused
on here is the con_id. Perhaps I missed this when looking over this patch, but
what "connector name" are we referring to here - the DRM connector name (e.g.
eDP-1), or something else? The reason I ask is because I wonder if connector
names are really the way that we want to be looking DRM connectors up, since I
believe it's possible for two different GPUs to have DRM connectors with the
same name.
> + const char *con_id;
> + /** @provider: dev_name() of the privacy_screen provider. */
> + const char *provider;
> +};
> +
> +void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup
> *lookup);
> +void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup
> *lookup);
> +
> +static inline void drm_privacy_screen_lookup_init(void)
> +{
> +}
> +static inline void drm_privacy_screen_lookup_exit(void)
> +{
> +}
> +
> +#endif
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
T'S how you reference other sections. I've always wondered!
> + enum drm_privacy_screen_status privacy_screen_sw_state;
> +
> /**
> * @hdr_output_metadata:
> * DRM blob property for HDR output metadata
> @@ -1409,6 +1439,18 @@ struct drm_connector {
> */
> struct drm_
gt; >
> > ctrl = old_ctrl;
> > if (panel->backlight.edp.intel.sdr_uses_aux) {
> > + /* Wait 100ms to ensure that panel is ready otherwise it
> > may not
> > + * set chosen backlight level
> > + */
> >
…whoops, that was supposed to be:
Reviewed-by: Lyude Paul
On Thu, 2021-09-09 at 12:18 -0400, Lyude Paul wrote:
> I thought I remembered an issue with this but looked up the previous emails,
> and it looks like that this change actually should be safe!
>
> Signed-off-by: Lyude Paul
I thought I remembered an issue with this but looked up the previous emails,
and it looks like that this change actually should be safe!
Signed-off-by: Lyude Paul
On Thu, 2021-09-09 at 15:51 +0300, Jani Nikula wrote:
> Extend the use of extended receiver cap at 0x2200 to co
an write a unit test to confirm we're not
overwriting the original DPCD! I don't know how much effort this would be
though so don't worry about it too much)
>
> BR,
> Jani.
>
>
> [1]
> https://patchwork.freedesktop.org/patch/msgid/20200901123226.4177-1-jani.nik...@intel.com
>
>
> >
> > BR,
> > Jani.
> >
> >
> > >
> > > > int ret;
> > > >
> > > > /*
> > > > --
> > > > 2.20.1
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Reviewed-by: Lyude Paul (assuming this still applies)
As I mentioned on IRC pretty much all of the DPCD backlight helpers already
made it upstream. There are some changes I'm working on right now for VESA
backlights that use PWM for controlling the brightness level (so we can
hopefully fix https
This looks great to me! Wasn't much to comment on here as most of this looks
fine to me. For the whole series:
Reviewed-by: Lyude Paul
This will be quite interesting to try getting working for nouveau
On Tue, 2021-08-17 at 23:51 +0200, Hans de Goede wrote:
> Hi all,
>
> Here is
gt; >ddc->dev.kobj, "ddc");
> return 0;
> +
> +err_free:
> + put_device(kdev);
> + return r;
> }
>
> void drm_sysfs_connector_remove(struct drm_connector *connector)
> @@ -374,11 +403,6 @@ void drm_sysfs_connector_status_event(struct
> drm_connector *connector,
> }
> EXPORT_SYMBOL(drm_sysfs_connector_status_event);
>
> -static void drm_sysfs_release(struct device *dev)
> -{
> - kfree(dev);
> -}
> -
> struct device *drm_sysfs_minor_alloc(struct drm_minor *minor)
> {
> const char *minor_str;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
sé and Lyude.
>
> Regards,
> Wayne
>
> ____
> > From: Lyude Paul
> > Sent: Thursday, June 17, 2021 03:47
> > To: José Roberto de Souza; intel-gfx@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org; Lin, Wayne
&
sed const variable 'hyperv_modifiers'
> >
> > Wayne Lin (2):
> > drm/dp_mst: Do not set proposed vcpi directly
> > drm/dp_mst: Avoid to mess up payload table by ports in stale topology
> >
> > drivers/gpu/drm/drm_dp_mst_topology.c
Reviewed-by: Lyude Paul
Will go ahead and push this to drm-misc-next-fixes, thanks
On Wed, 2021-06-16 at 12:44 -0700, José Roberto de Souza wrote:
> Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> ports in stale topology") added to calls to drm_dbg_kms()
.
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display
for instance).
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_display_types.h| 2 ++
.../drm/i915/display/intel_dp_aux_backlight.c | 29 ---
2 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display
-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/drm_dp_helper.c | 347 ++
.../drm/i915/display/intel_display_types.h| 5 +-
.../drm/i915/display/intel_dp_aux_backlight.c | 285 ++
include/drm
101 - 200 of 1282 matches
Mail list logo
