search for: reprob

On Tue, Sep 03, 2019 at 04:46:03PM -0400, Lyude Paul wrote: > Finally! For a very long time, our MST helpers have had one very > annoying issue: They don't know how to reprobe the topology state when > coming out of suspend. This means that if a user has a machine connected > to an MST topology and decides to suspend their machine, we lose all > topology changes that happened during that period. That can be a big > problem if the machine was connected to a d...

Finally! For a very long time, our MST helpers have had one very annoying issue: They don't know how to reprobe the topology state when coming out of suspend. This means that if a user has a machine connected to an MST topology and decides to suspend their machine, we lose all topology changes that happened during that period. That can be a big problem if the machine was connected to a different topology on...

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...

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 suspend/resume callbacks are disabled before the PM core calls ->suspend(), any calls to pm_runtime_get_sync() during this period will grab a runtime PM ref and return...

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 app...

...C. So, let's simply workaround this by telling userspace new > > > MST connectors are disconnected until we've finished probing their PBN. > > > Since we always send a hotplug event at the end of the link address > > > probing process, userspace will still know to reprobe the connector when > > > we're ready. > > > > > > Signed-off-by: Lyude Paul <lyude at redhat.com> > > > Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST > > > atomic check") > > > Cc: Mikita Lipski &...

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 input port (or vice versa). If we forget to update this bit of information, we'll potentially ignore a valid PDT change on a downstream port because we think it...

...ector to fail > with -ENOSPC. So, let's simply workaround this by telling userspace new > MST connectors are disconnected until we've finished probing their PBN. > Since we always send a hotplug event at the end of the link address > probing process, userspace will still know to reprobe the connector when > we're ready. > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") > Cc: Mikita Lipski <mikita.lipski at amd.com> > Cc: Alex Deucher <alexand...

...space > > > > new > > > > MST connectors are disconnected until we've finished probing their > > > > PBN. > > > > Since we always send a hotplug event at the end of the link address > > > > probing process, userspace will still know to reprobe the connector > > > > when > > > > we're ready. > > > > > > > > Signed-off-by: Lyude Paul <lyude at redhat.com> > > > > Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to > > > > MST > >...

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

...rogress] What's new: * By default the MBP boots with the display switched to the discrete GPU but it can be forced to the integrated GPU with an EFI boot variable. Here's a handy tool for that: https://github.com/0xbb/gpu-switch v1 didn't work in this configuration, v2 does. * 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 registers. That is a...

...It's not 100% reproducible, but it's at least 90% so it's not difficult for me to test at all. Also, reverting this commit makes no difference either. Note that while that commit only changed nouveau, scheduled_work() is exactly how a number of other drivers (i915 for instance) handle reprobing like this as well. The reason being that we can't do full connector reprobing in our runtime resume thread because we could deadlock if someone else is holding a modesetting lock we need and waiting on us to resume at the same time (there's a number of other bug fixes in nouveau for othe...

...uld enable said connector to fail with -ENOSPC. So, let's simply workaround this by telling userspace new MST connectors are disconnected until we've finished probing their PBN. Since we always send a hotplug event at the end of the link address probing process, userspace will still know to reprobe the connector when we're ready. Signed-off-by: Lyude Paul <lyude at redhat.com> Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") Cc: Mikita Lipski <mikita.lipski at amd.com> Cc: Alex Deucher <alexander.deucher at amd.com> Cc:...

...nnels ... only the 100xp wildcard is recognized....i get a sound when pressing the keypad of the phone connected to usb device , but i get no dialtone nor does asterisk identify pick up event....ont eh otehr hand it issues a notification in case of an incoming call... I have tried rmmod and then reprobing but that does not help....i have the dialtone option in my phone.conf.... please advise thanks digvijay _________________________________________________________________ Looking for something? Cant find it anywhere? http://go.msnserver.com/IN/50756.asp Log onto baazee.com

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...

...xplicitly designed to do so. This can be explained pretty simply by the fact that there's more situations that would involve updating the port information based on a link address response as opposed to a connection status notification than the driver's initial topology probe. Case in point: reprobing link addresses after suspend/resume. Since we're about to start using drm_dp_add_port() differently for suspend/resume reprobing, let's rename both functions to clarify what they actually do. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc:...

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 input port (or vice versa). If we forget to update this bit of information, we'll potentially ignore a valid PDT change on a downstream port because we think it...

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 get optimus to work. After trying several different sets of instructions I never found a working confi...

...gt; with -ENOSPC. So, let's simply workaround this by telling userspace new > > MST connectors are disconnected until we've finished probing their PBN. > > Since we always send a hotplug event at the end of the link address > > probing process, userspace will still know to reprobe the connector when > > we're ready. > > > > Signed-off-by: Lyude Paul <lyude at redhat.com> > > Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST > > atomic check") > > Cc: Mikita Lipski <mikita.lipski at amd.com&gt...

...g plugged into it currently results in a bogus EDID retrieval error in the kernel log. Additionally, most dongles won't send another long HPD signal if the user suddenly plugs something in, they'll only send a short HPD IRQ with the expectation that the source will check the sink count and reprobe the connector if it's changed - something we don't actually do. As a result, nothing will happen if the user plugs the dongle in before plugging something into the dongle. So, let's fix this by checking the sink count in both nouveau_dp_probe_dpcd() and nouveau_dp_irq(), and reprobing...