search for: reprobed

...ess(). We then introduce suspend/resume reprobing > by introducing drm_dp_mst_topology_mgr_invalidate_mstb(), which we call > in drm_dp_mst_topology_mgr_suspend() to traverse the in-memory topology > state to indicate that each mstb needs it's link address resent and PBN > resources reprobed. > > On resume, we start back up &mgr->work and have it reprobe the topology > in the same way we would on a hotplug, removing any leftover ports that > no longer appear in the topology state. > > Cc: Juston Li <juston.li at intel.com> > Cc: Imre Deak <imre.de...

...rm_dp_send_link_address(). We then introduce suspend/resume reprobing by introducing drm_dp_mst_topology_mgr_invalidate_mstb(), which we call in drm_dp_mst_topology_mgr_suspend() to traverse the in-memory topology state to indicate that each mstb needs it's link address resent and PBN resources reprobed. On resume, we start back up &mgr->work and have it reprobe the topology in the same way we would on a hotplug, removing any leftover ports that no longer appear in the topology state. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjä...

This is the large series for adding MST suspend/resume reprobing that I've been working on for quite a while now. In addition, I: - Refactored and cleaned up any code I ended up digging through in the process of understanding how some parts of these helpers worked. - Added some debugging tools along the way that I ended up needing to figure out some issues in my own code Note that

On most systems with ACPI hotplugging support, it seems that we always receive a hotplug event once we re-enable EC interrupts even if the GPU hasn't even been resumed yet. This can cause problems since even though we schedule hpd_work to handle connector reprobing for us, hpd_work synchronizes on pm_runtime_get_sync() to wait until the device is ready to perform reprobing. Since runtime

Hi Daniel, On Wed, Aug 12, 2015 at 04:16:25PM +0200, Daniel Vetter wrote: > > * Reprobing if the inactive GPU initializes before the apple-gmux module: > > v1 used Matthew Garrett's approach of adding a driver callback. > > v2 simply generates a hotplug event instead. nouveau polls its outputs > > every 10 seconds so we want it to poll immediately once apple-gmux

On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote: > On Thu, 2020-03-05 at 15:11 +0200, Ville Syrj?l? wrote: > > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote: > > > It's next to impossible for us to do connector probing on topologies > > > without occasionally racing with userspace, since creating a connector > > > itself causes a

This probably hasn't caused any problems up until now since it's probably nearly impossible to encounter this in the wild, however if we were to receive a connection status notification from the MST hub after resume while we're in the middle of reprobing the link addresses for a topology then there's a much larger chance that a port could have changed from being an output port to

On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote: > It's next to impossible for us to do connector probing on topologies > without occasionally racing with userspace, since creating a connector > itself causes a hotplug event which we have to send before probing the > available PBN of a connector. Even if we didn't have this hotplug event > sent, there's still

On Thu, 2020-03-05 at 20:29 +0200, Ville Syrj?l? wrote: > On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote: > > On Thu, 2020-03-05 at 15:11 +0200, Ville Syrj?l? wrote: > > > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote: > > > > It's next to impossible for us to do connector probing on topologies > > > > without occasionally

While working on refactoring how we handle connector hotplugging/probing + a bunch of misc DP stuff, I found a bunch of runtime_pm errors that were mostly introduced by me at one point. Oops. A lot of these aren't triggered consistently on a lot of systems, so it's not terribly surprising these got swept under the rug. Lyude Paul (9): drm/nouveau/kms: Handle -EINPROGRESS in

This is a follow-up to the v1 posted in April: http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html Patches 1 - 17 enable GPU switching on the pre-retina MacBook Pro. These were tested successfully by multiple people and solve two tickets in Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 https://bugs.freedesktop.org/show_bug.cgi?id=61115 Patches 18 - 22 are a

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 > equivalent to what I proposed. > > I'm always suspicious of singleton solutions like this (using > schedule_work() in runtime_resume()) because usually they seem to be > solving a generic problem that should happen on many kinds of > hardware.

It's next to impossible for us to do connector probing on topologies without occasionally racing with userspace, since creating a connector itself causes a hotplug event which we have to send before probing the available PBN of a connector. Even if we didn't have this hotplug event sent, there's still always a chance that userspace started probing connectors before we finished probing

hi.. nope I do know about x100p being the fxo and the usb device being the fxs ....fxo using fxs signalling and fxs using fxo signalling and it is reflected suitably in my zapata.conf and zaptel.conf... The problem is that the S100U usb device is not identified upon zap show channels ... only the 100xp wildcard is recognized....i get a sound when pressing the keypad of the phone connected to

This is the final portion of the large series for adding MST suspend/resume reprobing that I've been working on for quite a while now. In addition, I: * Refactored and cleaned up any code I ended up digging through in the process of understanding how some parts of these helpers worked. * Added some debugging tools along the way that I ended up needing to figure out some issues in my own

The names for these functions are rather confusing. drm_dp_add_port() sounds like a function that would simply create a port and add it to a topology, and do nothing more. Similarly, drm_dp_update_port() would be assumed to be the function that should be used to update port information after initial creation. While those assumptions are currently correct in how these functions are used, a quick

This probably hasn't caused any problems up until now since it's probably nearly impossible to encounter this in the wild, however if we were to receive a connection status notification from the MST hub after resume while we're in the middle of reprobing the link addresses for a topology then there's a much larger chance that a port could have changed from being an output port to

Because I am on a macbook the VBIOS might be wonky. I tried turning off nVidia and using intel. The result was a blank screen. I know other people had the same bug which was something to do with reprobing lvds?! I saw patches go by and every time I tried one the results were the same. fail. I was actually about to post a bug report to the intel (i915) people about it. I tried to work out how to

On Thu, 2020-03-05 at 15:11 +0200, Ville Syrj?l? wrote: > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote: > > It's next to impossible for us to do connector probing on topologies > > without occasionally racing with userspace, since creating a connector > > itself causes a hotplug event which we have to send before probing the > > available PBN of a

This is another bit that we never implemented for nouveau: dongle detection. When a "dongle", e.g. an active display adaptor, is hooked up to the system and causes an HPD to be fired, we don't actually know whether or not there's anything plugged into the dongle without checking the sink count. As a result, plugging in a dongle without anything plugged into it currently results