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 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 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
end this is:
Acked-by: Lyude Paul
I'd very much like Thomas Zimmerman to verify that this patch is OK though
with an R-b before we push anything upstream.
On Fri, 2022-01-14 at 10:47 +0100, Jocelyn Falempe wrote:
> On some server with MGA G200e (rev 42), booting with Legacy BIOS,
> T
up the initial attempt at
removing the non-atomic MST code in the DRM helpers now. If my theory ends up
being correct here, I can fix this in my rewrite of the MST payload management
code. But I figured it might be worth mentioning in the mean time in case you
think it might be relevant to the pr
On Tue, 2022-01-18 at 20:58 -0500, Lyude Paul wrote:
> Hey - so, the original issue here was that payloads were not always deleted
> when we expected them to be - correct?
>
> If I'm remembering that correctly, then (and I'm not 100% sure on this yet)
> I
> might al
super appreciated and likely
will make reviewing the patches that will come out of this easier.
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
On Wed, 2022-01-19 at 17:56 -0500, Lyude Paul wrote:
> Hi! I'm writing this email because I'm currently finishing up removing
> pretty
> much all of the non-atomic MST code in drm_dp_mst_topology_mgr.c as it's
> really made it difficult to maintain MST over time. As w
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&#
Reviewed-by: Lyude Paul
On Tue, 2022-01-25 at 00:58 +0800, Zhou Qingyang wrote:
> In nvkm_acr_hsfw_load_bl(), the return value of kmalloc() is directly
> passed to memcpy(), which could lead to undefined behavior on failure
> of kmalloc().
>
> Fix this bug by using kmemdup() ins
For this patch:
Reviewed-by: Lyude Paul
On Fri, 2022-01-28 at 00:36 -0800, Lucas De Marchi wrote:
> iosys-map is the new name for dma-buf-map and will gain new
> capabitilities. Replace with the new API in nouveau.
>
> Signed-off-by: Lucas De Marchi
> ---
> drive
t;code_off, desc->code_size,
> > GFP_KERNEL);
> > nvkm_firmware_put(fw);
> > - return 0;
> > + if (!hsfw->imem)
> > + return -ENOMEM;
> > + else
> > + return 0;
> > }
> >
> > int
> > --
> > 2.25.1
> >
>
> As stated before, umn.edu is still not allowed to contribute to the
> Linux kernel. Please work with your administration to resolve this
> issue.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
e this fix myself later and send another fix if this ends up
being valid.
Signed-off-by: Lyude Paul
Cc: Greg KH
Cc: Ben Skeggs
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/no
On Fri, 2022-01-28 at 14:53 -0500, Alex Deucher wrote:
> On Fri, Jan 28, 2022 at 2:20 PM Lyude Paul wrote:
> >
> > Sigh-thank you for catching this - I had totally forgot about the umn.edu
> > ban.
> > I pushed this already but I will go ahead and send a revert for
on further reconsideration: Self-NAKing this. I don't see any issues with
those patches.
On Fri, 2022-01-28 at 14:29 -0500, Lyude Paul wrote:
> This reverts commit 2343bcdb4747d4f418a4daf2e898b94f86c24a59.
>
> Unfortunately, as Greg pointed out I totally missed the fact that thi
Reviewed-by: Lyude Paul
Will add to the topic branch right now
On Wed, 2021-10-27 at 18:39 -0400, Alex Deucher wrote:
> Need to guard some things with CONFIG_DRM_AMD_DC_DCN.
>
> Fixes: 41724ea273cdda ("drm/amd/display: Add DP 2.0 MST DM Support")
> Signed-off-by: Alex Deu
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
thing else - except for having to maintain a payload table and
bandwidth limitations across a shared connection. So pretty much everything
related to enabling or disabling streams should be in the atomic commit phase
(with any bandwidth calculations done beforehand, WIP...). I'm going to say,
let's figure out where this is happening first. I've got the debugging patches
for this ready and will send them to you now.
>
> > Also, I'm still working on the debugging stuff btw!
> Much appreciate Lyude! Thanks!
>
> >
> > --
> > Cheers,
> > Lyude Paul (she/her)
> > Software Engineer at Red Hat
> --
> Regards,
> Wayne Lin
--
Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
--
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!
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
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")
Reviewed-by: Ville Syrjälä
Cc: # v5.12+
---
.../drm/i915/display
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/nouv
ix at least one (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")
---
d
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_
DPAUX I2C transfer helper may access
> aux->drm_device. Hence v1 patch isn't correct anyways.
JFYI - unless I'm misunderstanding you, the aux->drm_dev accesses in the DPAUX
i2c transfer functions are just from the various drm_{dbg,err,etc.} calls,
which means that they all should be able to handle aux->drm_dev being NULL. If
you can set aux->drm_dev before i2c transfers start that's more ideal, since
otherwise you'll see the AUX device name as "(null)" in the kernel log, but
any point before device registration should work.
>
> For now I'll try to test more the ad-hoc variant with Thomas and send it
> as v2 if we won't have a better solution.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
ver many ms are left 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: 4
Acked-by: Lyude Paul
On Wed, 2021-11-10 at 14:31 +0100, Karol Herbst wrote:
> Some side notes on this. Atm we do want to use gitlab for bug tracking and
> merge requests. But due to the nature of the current linux kernel
> development, we can only do so for nouveau interna
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 det
args->v0.handle,
> &args->v0.length);
> + if (ret)
> + return ret;
> if (type == NVKM_OBJECT_MAP_IO)
> args->v0.type = NVIF_IOCTL_MAP_V0_IO;
> else
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
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
I wonder what vivo's interested in this for!
Anyway:
Reviewed-by: Lyude Paul
Do you need me to push this to drm-misc-next for you?
On Tue, 2021-11-16 at 17:48 -0800, Bernard Zhao wrote:
> This patch try to fix the potential memleak in error branch.
>
> Signed-off-by
Reviewed-by: Lyude Paul
Will push this to drm-misc in a bit
On Thu, 2021-11-18 at 14:13 +0300, Dan Carpenter wrote:
> The nvkm_acr_lsfw_add() function never returns NULL. It returns error
> pointers on error.
>
> Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to
ver many ms are left 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_
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 det
intel_dp
V2:
* Move panel 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
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
a pinned
buffer. As well, add back the hunks in ttm_bo_del_from_lru() that were
removed which checked whether we want to call
bdev->driver->del_from_lru_notify() or not. We do this last part to avoid
calling the hook when the bo in question was already removed from the LRU.
Signed-off-by:
Reviewed-by: Lyude Paul
Guessing it's fine if I push this with your sob and review added?
On Tue, 2021-01-05 at 12:45 +0100, Christian König wrote:
> From: Lyude Paul
>
> Recently a regression was introduced which caused TTM's buffer eviction to
> attempt to evict alrea
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
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
() 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:
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:
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
Reviewed-by: Lyude Paul
On Wed, 2021-01-13 at 08:07 +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
>
> Cc: Ben 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
ht() in intel_pwm_setup_backlight() 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
Re
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
Reviewed-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
On Fri, 2021-12-17 at 18:56 -0800, Yizhuo Zhai wrote:
> In function nvkm_ioctl_map(), the variable "type" could be
> uninitialized if "nvkm_object_map()" returns error code, however,
> it does not check the return value and directly use the
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 drm_dp.c
mgr->cbs->notify_csn_disconnection(port->connector);
> +
> if (port->connector)
> drm_modeset_unlock(&mgr->base.lock);
> else if (create_connector)
> drm_dp_mst_port_add_connector(mstb, port);
>
> +
> out:
>
On Wed, 2016-08-03 at 18:00 +0300, Ville Syrjälä wrote:
> On Tue, Aug 02, 2016 at 06:37:37PM -0400, Lyude wrote:
> >
> > Now that we can hook into update_crtcs and control the order in which we
> > update CRTCs at each modeset, we can finish the final step of fixing
> > Skylake's watermark handl
On Thu, 2016-08-18 at 09:39 +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 17-08-16 om 21:55 schreef Lyude:
> >
> > Since the watermark calculations for Skylake are still broken, we're apt
> > to hitting underruns very easily under multi-monitor configurations.
> > While it would be lovely if this
rm_sysfs_release(struct device *dev)
> > {
> > kfree(dev);
> > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > index 4f311e836cdc..d454ef617b2c 100644
> > --- a/include/drm/drm_sysfs.h
> > +++ b/include/drm/drm_sysfs.h
> > @@ -4,10 +4,13 @@
> >
> > struct drm_device;
> > struct device;
> > +struct drm_connector;
> > +struct drm_property;
> >
> > int drm_class_device_register(struct device *dev);
> > void drm_class_device_unregister(struct device *dev);
> >
> > void drm_sysfs_hotplug_event(struct drm_device *dev);
> > -
> > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > + struct drm_property *property);
> > #endif
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drivers/gpu/drm/drm_dp_mst_topology.c | 106
> ++---
> drivers/gpu/drm/drm_sysfs.c| 23 +
> drivers/gpu/drm/nouveau/nouveau_connector.c| 2 +-
> include/drm/drm_dp_helper.h| 4 +
> include/drm/drm_dp_ms
Whoops-one more thing I forgot to mention. This is just personal preference
for me, but if you're ccing me on any of the patches in the series feel free
to just do it for all of them. Makes my inbox a little less confusing to look
at
On Thu, 2019-05-16 at 15:54 -0400, Lyude Paul wrote:
criptive symlinks to the
> MST aux devices.
>
> Cc: Ville Syrjälä
> Cc: Lyude Paul
> Signed-off-by: Leo Li
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/g
the connector gives udev the
> ability to access the connector device's attributes. This will come in
> handy when writing udev rules to create more descriptive symlinks to the
> MST aux devices.
>
> Cc: Ville Syrjälä
> Cc: Lyude Paul
> Signed-off-by: Leo Li
> ---
&
Reviewed-by: Lyude Paul
On Thu, 2019-05-16 at 11:18 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> Set the connector's kernel device as the parent for the aux kernel
> device. This allows udev rules to access connector attributes when
> creating symlinks to aux d
l port, whereas the MST displays will NAK.
>
> In light of these discrepancies, it's simpler to expose all downstream
> ports - both physical and logical - and let the user decide what to use.
>
> Cc: Lyude Paul
> Signed-off-by: Ville Syrjälä
> Signed-off-by
005018] intel_dp_hpd_pulse+0x205/0x370 [i915]
> [ +0,004836] i915_digport_work_func+0xbb/0x140 [i915]
> [ +0,005108] process_one_work+0x245/0x610
> [ +0,004027] worker_thread+0x37/0x380
> [ +0,003684] ? process_one_work+0x610/0x610
> [ +0,004184] kthread+0x119/0
On Fri, 2019-05-24 at 01:28 +0300, Imre Deak wrote:
> On Thu, May 23, 2019 at 06:09:56PM -0400, Lyude Paul wrote:
> > Patch mostly looks good to me, one comment below
> >
> > On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> > > Fix the breakage resulting in t
al more difficult than it might seem, mostly due to the fact that
we have to use the i2c bus during runtime resume of the GPU, we instead
opt for the easiest solution: don't let userspace access i2c busses on
the GPU at all while it's in runtime suspend.
Changes since v1:
* Also disable i2c bus
On Thu, 2019-04-11 at 08:48 +1000, Ben Skeggs wrote:
> On Wed, 10 Apr 2019 at 06:23, Lyude Paul wrote:
> > For a while, we've had the problem of i2c bus access not grabbing
> > a runtime PM ref when it's being used in userspace by i2c-dev, resulting
> > in nouve
Helgaas wrote:
> > > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote:
> > > > On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote:
> > > > > On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote:
> > > > > > On Tue, Feb 12, 2019 at 05:02
/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index e2266ac..13f1005 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1143,7 +1143,7 @@ int drm_dp_aux_register(struct drm_dp_aux *aux)
> strlcpy(aux->ddc.name, aux->na
lude/drm/drm_dp_helper.h
> @@ -1265,6 +1265,10 @@ struct drm_dp_aux {
>* @cec: struct containing fields used for CEC-Tunneling-over-AUX.
>*/
> struct drm_dp_aux_cec cec;
> + /**
> + * @is_remote: Is this "AUX CH" actually using sideband messaging.
> + */
> + bool is_remote;
&g
On Wed, 2019-04-17 at 23:10 +, Li, Sun peng (Leo) wrote:
>
>
> On 2019-04-16 6:16 p.m., Lyude Paul wrote:
> > Sorry for the slow response, I've been really busy ;_;
>
> No worries :)
>
> > On Fri, 2019-04-12 at 12:05 -0400, sunpeng...@amd.com wrote:
lgtm
Reviewed-by: Lyude Paul
On Mon, 2019-04-22 at 19:56 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> In preparation for adding aux devices for DP MST, make the IDR
> non-cyclic. That way, hotplug cycling MST devices won't needlessly
> increment the minor version in
topology_mgr *mgr,
> int pbn);
>
> +void drm_dp_build_mst_prop_path(const struct drm_dp_mst_branch *mstb,
> +int pnum,
> + char *proppath,
> +size_t proppath_
Any update on this? This has been waiting for a while now
On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote:
> [+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime)
> resume")]
--
Cheers,
Lyude Paul
_
ces like this aren't reset into a clean state during a system
reboot, is that correct?
>
> > Do we want to have this discussion on the bz btw, or is this email
> > thread fine?
>
> Email is fine.
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 2019-04-24 at 23:52 +0300, Ville Syrjälä wrote:
> On Wed, Apr 24, 2019 at 08:40:30PM +, Li, Sun peng (Leo) wrote:
> >
> >
> > On 2019-04-24 1:26 p.m., Lyude Paul wrote:
> > > Closer, but are we sure we want to use the MST prop path for this? Why
> &g
On Wed, 2019-04-24 at 17:36 -0500, Bjorn Helgaas wrote:
> On Wed, Apr 24, 2019 at 03:16:37PM -0400, Lyude Paul wrote:
> > On Wed, 2019-04-24 at 13:59 -0500, Bjorn Helgaas wrote:
> > > Not being a scheduled work expert, I was unsure if this experiment was
> > > eq
el_dp_mst_resume(). From there, drm_dp_destroy_connector_work() will
eventually send the hotplug event.
Signed-off-by: Lyude Paul
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte
Cc: Dave Airlie
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: inte
ST topologies connected on this machine.
Signed-off-by: Lyude Paul
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte
Cc: Dave Airlie
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Imre Deak
Cc: intel-...@lists.freedesktop.org
Cc: # v3.17+
---
dr
This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst()
already sends a hotplug on its own from drm_dp_destroy_connector_work()
after destroying connectors in the MST topology.
Signed-off-by: Lyude Paul
Cc: Imre Deak
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.
e patch,
"drm/i915: Don't send MST hotplugs during resume"
Lyude Paul (3):
drm/i915: Block fbdev HPD processing during suspend
drm/i915: Don't send MST hotplugs during resume
drm/i915: Don't send hotplug in intel_dp_check_mst_status()
drivers/gpu/drm/i915/inte
don't send any hotplug events during resume if the MST topology
fails to come up. Just rely on the DP MST helpers to send them for us.
Signed-off-by: Lyude Paul
Cc: Imre Deak
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
This is much louder then we want. VCPI allocation failures are quite
normal, since they will happen if any part of the modesetting process is
interrupted by removing the DP MST topology in question. So just print a
debugging message on VCPI failures instead.
Signed-off-by: Lyude Paul
Fixes
cking on them. This fixes the warnings during
suspend/resume when a topology is removed from the system, and allows
us to once again restore the atomic state on resume without any issues.
Signed-off-by: Lyude Paul
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI all
So, fix this by using the new drm_atomic_state.suspend_or_resume hook in
order to force us to retrieve a VCPI allocation when restoring a pipe's
atomic state. This is safe, since drm_dp_atomic_find_vcpi_slots() will
just return the VCPI allocation we had pre-suspend.
Signed-off-by: Lyude Paul
Cc: Daniel Vett
_vcpi() is called on a port with
no VCPI allocation. Additionally, clean up the surrounding kerneldoc
while we're at it since the port is assumed to be kept around because
the DRM driver is expected to hold a malloc reference to it, not just
us.
Signed-off-by: Lyude Paul
Fixes: eceae14724
This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.
Lyude Paul (3):
drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()
drm/atomic: Add drm_atomic_state->suspend_or_resume
This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst()
already sends a hotplug on its own from drm_dp_destroy_connector_work()
after destroying connectors in the MST topology.
Signed-off-by: Lyude Paul
Cc: Imre Deak
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.
e patch,
"drm/i915: Don't send MST hotplugs during resume"
Lyude Paul (3):
drm/i915: Block fbdev HPD processing during suspend
drm/i915: Don't send MST hotplugs during resume
drm/i915: Don't send hotplug in intel_dp_check_mst_status()
drivers/gpu/drm/i915/int
don't send any hotplug events during resume if the MST topology
fails to come up. Just rely on the DP MST helpers to send them for us.
Signed-off-by: Lyude Paul
Cc: Imre Deak
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
401 - 500 of 2439 matches
Mail list logo
