@gmail.com
Lyude Paul (5):
drm/nouveau/kms/nv40-/backlight: Assign prop type once
drm/nouveau/kms: Don't probe eDP connectors more then once
drm/i915/dp: Remove redundant AUX backlight frequency calculations
drm/dp: Extract i915's eDP backlight code into DRM helpers
drm/nouveau/kms/n
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
ching
this value in intel_panel.backlight, and re-writing it as-needed.
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
.../drm/i915/display/intel_display_types.h| 1 +
.../drm/i915/display/intel_dp_aux_backlight.c | 64 ++-
2 files ch
eDP doesn't do hotplugging, so there's no reason for us to reprobe it (unless a
connection status change is being forced, of course).
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++
1 fi
of brightness levels
* Basic probing of backlight capabilities
* Helpers for enabling and disabling the backlight
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/drm_dp_helper.c | 332 ++
.../drm/i915/display/i
ntrols working.
For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.
Signed-
Poke, can we please get some reviews on this? It's been over a week.
On Fri, 2020-12-04 at 17:35 -0500, Lyude Paul wrote:
> A while ago we ran into issues while trying to enable the eDP backlight
> control interface as defined by VESA, in order to make the DPCD
> backlight con
On Wed, 2020-12-23 at 18:37 +0200, Jani Nikula wrote:
> On Fri, 04 Dec 2020, Lyude Paul wrote:
> > Currently, every different type of backlight hook that i915 supports is
> > pretty straight forward - you have a backlight, probably through PWM
> > (but maybe DPCD), with a s
at we weren't able to properly
automatically detect DPCD backlight controls on previously.
Series-wide changes in v3:
* Pass down brightness values to enable/disable backlight callbacks in a
separate patch
* Rebase
Lyude Paul (4):
drm/i915: Keep track of pwm-related backlight hooks separately
ve intel_dp_aux_init_bcklight_funcs() call to bottom of
intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/inte
_backlight() if we fail
to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
Cc: thay...@n
els in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).
v3:
* Rebase
Signed-off-by: Lyude Paul
Reviewed-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_dp_aux_backli
of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.
v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
intel_edp_init_connector()
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Kh
t; > > > > dg1_port_to_ddc_pin(dev_priv, port); -else if
> > > > > (IS_ROCKETLAKE(dev_priv))
> > > > > +else if (IS_ROCKETLAKE(dev_priv) || (IS_COMETLAKE(dev_priv) &&
> > > > > + HAS_PCH_TGP(dev_priv)))
> > > > > ddc
at we weren't able to properly
automatically detect DPCD backlight controls on previously.
Series-wide changes in v3:
* Pass down brightness values to enable/disable backlight callbacks in a
separate patch
* Rebase
Lyude Paul (4):
drm/i915: Keep track of pwm-related backlight hooks separately
() instead of
indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Cc:
els in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).
v3:
* Rebase
Signed-off-by: Lyude Paul
Reviewed-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_dp_aux_backli
forget to return from intel_dp_aux_hdr_get_backlight() if we fail
to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
Signed-off-by: Lyude Paul
Acked-by:
of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.
v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
intel_edp_init_connector()
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Kh
Reviewed-by: Lyude Paul
Let me know when you've pushed this upstream and I'll go ahead and send out a
rebased version of my backlight series.
On Fri, 2021-01-08 at 17:28 +0200, Jani Nikula wrote:
> The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight()
> f
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()
(1):
> > drm/hyperv: Fix unused 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
> >
&
ks José 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, Wa
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
; PASS
> 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
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_
KMS("%s ecoding 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
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
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
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:
...
(ahem, some 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
>
ted
backlight features 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):
vel_to_pwm() 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 |
oking 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&
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 -
el's CI that had an issue
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
Revie
panels, hopefully you can all
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_
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!
>
rivers/gpu/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
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
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
> > intel_crtc_state *crtc_state,
> >
> > 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
es`
> + */
So THAT'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
; + /**
> + * @sw_state: The privacy-screen's software state, see
> + * :ref:`Standard Connector
> Properties`
> + * for more info.
> + */
> + 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
ier_head: privacy-screen notifier head. */
> + struct blocking_notifier_head notifier_head;
> /**
> * @ops: &struct drm_privacy_screen_ops for this privacy-screen.
> * This is NULL if the driver has unregistered the privacy-screen.
> @@ -77,4 +79,6 @@ 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);
>
> +void drm_privacy_screen_call_notifier_chain(struct drm_privacy_screen
> *priv);
> +
> #endif
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
lcdshadow_set_sw_state(lcdshadow_dev, state);
> + mutex_unlock(&lcdshadow_dev->lock);
> +
> + drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
> +
> + 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(&dytc_ignore_event, -1, 0))
> dytc_profile_refresh();
> }
> +
> + if (lcdshadow_dev && hkey_event == TP_HKEY_EV_PRIVACYGUARD_TOGGLE) {
> + mutex_lock(&lcdshadow_dev->lock);
> + lcdshadow_get_hw_state(lcdshadow_dev);
> + mutex_unlock(&lcdshadow_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
heroo_client_probe_defer(pdev))
> return -EPROBE_DEFER;
>
> + /*
> + * 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(&pdev->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
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,
>
> He
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
lf 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
>
--
Chee
s we really had 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
backlights
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/-/is
ines
though, by manually patching i915 to force 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_ba
panels, hopefully you can all
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
nable: Does the panel support the AUX enable cap? Always %false
> > 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
s we really had 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
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 -
backlights
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/-/is
panels, hopefully you can all
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
el's CI that had an issue
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
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
> >
ted
backlight features 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-: Explic
backlights
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/-/is
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 -
oking 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&
el's CI that had an issue
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
panels, hopefully you can all
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
On Mon, 2021-05-03 at 06:06 +0300, Ville Syrjälä wrote:
> On Fri, Apr 30, 2021 at 06:34:28PM -0400, Lyude Paul wrote:
> > Noticed this while fixing another issue in drm_dp_read_downstream_info(),
> > the open coded DP_DOWNSTREAMPORT_PRESENT check here just duplicates what
> >
ching
this value in intel_panel.backlight, and re-writing it as-needed.
Changes since v1:
* Wrap panel->backlight.edp.vesa.pwm_freq_pre_divider in
DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP check - Jani
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
.../
s:
* Split up the changes to intel's backlight code into separate patches
v4 series-wide changes:
* Don't forget to actually include the patch that starts using these
helpers in nouveau
v5 series-wide changes:
* Rebase
* Use new drm_dbg_*() logging helpers
Lyude Paul (9):
drm/i915/dpcd_
t doing DP work
again, also because I'd rather not mix a tree-wide refactor like that in
with a patch series intended to be around introducing DP backlight helpers.
So, for now let's just handle the return values from each function
correctly.
Signed-off-by: Lyude Paul
Reviewed-by: Rodrig
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
---
.../gpu/drm/i915/display
_COUNT
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/i9
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(+
st return early.
Signed-off-by: Lyude Paul
---
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/intel_dp_aux_backlight.c
ind
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
---
.../drm/i915/display
functions
Signed-off-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 ++
ntrols working.
For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.
Signed-
Reviewed-by: Lyude Paul
Will let this sit on the list for a few days to see if anyone's got any
objections and then I'll go ahead and push it
On Wed, 2021-05-12 at 17:00 -0400, Nikola Cornij wrote:
> [why]
> Link rate in kHz is what is eventually required to calculate the
a bunch of R-bs that got dropped by accident
Lyude Paul (9):
drm/i915/dpcd_bl: Remove redundant AUX backlight frequency
calculations
drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values correctly
drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit
drm/i915
t doing DP work
again, also because I'd rather not mix a tree-wide refactor like that in
with a patch series intended to be around introducing DP backlight helpers.
So, for now let's just handle the return values from each function
correctly.
Signed-off-by: Lyude Paul
Reviewed-by: Rodrig
ching
this value in intel_panel.backlight, and re-writing it as-needed.
Changes since v1:
* Wrap panel->backlight.edp.vesa.pwm_freq_pre_divider in
DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP check - Jani
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
.../
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(+
ntrols working.
For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.
Signed-
functions
Signed-off-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 ++
_COUNT
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/i9
st return early.
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/d
> &connector->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
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,
>
> Her
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
you can 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
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
…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
On Tue, 2021-03-23 at 16:06 +0200, Jani Nikula wrote:
> On Thu, 18 Mar 2021, Lyude Paul wrote:
> > Actually-NAK this. I just realized I've been misreading the bug and that
> > this
> > doesn't actually seem to be fixed. Will resend once I figure out what's
&
t=3" and just see if your backlight controls still
work as expected.
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc.
* Address most checkpatch issues ('most' as in all except for one line
going two chars over 100 in "drm/dp_mst: Pass drm_dp_mst_topology_mgr
to drm_dp_get_vc_payload_bw()" as this was the style in use
previously, and 2 chars over the limit looks nicer then trying to
line-
ctly
Signed-off-by: Lyude Paul
Acked-by: Randy Dunlap
---
include/drm/drm_dp_helper.h | 44 ++---
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 632ad7faa006..5efa0d329b67 10064
1 - 100 of 1285 matches
Mail list logo
