search for: reprobe

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

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 issues in my own code Note that

...re the PM core calls ->suspend(), any calls to pm_runtime_get_sync() during this period will grab a runtime PM ref and return immediately with -EACCES. Because we schedule hpd_work from our ACPI HPD handler, and hpd_work synchronizes on pm_runtime_get_sync(), this causes us to launch a connector reprobe immediately even if the GPU isn't actually resumed just yet. This causes various warnings in dmesg and occasionally, also prevents some displays connected to the dedicated GPU from coming back up after suspend. Example: usb 1-4: USB disconnect, device number 14 usb 1-4.1: USB disconnect, devic...

...n switchable separately from the panel). So basically we'd have to initialize the driver normally, and if intel_lvds_init() or intel_edp_init_connector() fail we'd have to somehow pass that up the call chain so that i915_pci_probe() can return -EPROBE_DEFER. And whenever we're asked to reprobe we'd repeat initialization of the LVDS or eDP connector. I'm wondering what the benefit is compared to just keeping the connector in the mode configuration, but with status disconnected, and reprobing it when the ->output_poll_changed callback gets invoked? Because that's what nouve...

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

...needed if the port's exposed to userspace */ - if (port->connector) + if (port->connector) { + if (!port->input && conn_stat->input_port) { + /* + * We can't remove a connector from an already exposed + * port, so just throw the port out and make sure we + * reprobe the link address of it's parent MSTB + */ + drm_dp_mst_topology_unlink_port(mgr, port); + mstb->link_address_sent = false; + dowork = true; + goto out; + } + + /* + * Locking is only needed if the port's exposed to userspace + */ drm_modeset_lock(&mgr->base.loc...

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

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

...'m looking forward to your feedback. Thanks, Lukas Dave Airlie (1): vga_switcheroo: Lock/unlock DDC lines Lukas Wunner (15): vga_switcheroo: Lock/unlock DDC lines harder Revert "vga_switcheroo: Add helper function to get the active client" Revert "vga_switcheroo: add reprobe hook for fbcon to recheck connected outputs." drm/nouveau: Lock/unlock DDC lines on probe vga_switcheroo: Generate hotplug event on handler and proxy registration drm/i915: Preserve SSC earlier drm/i915: Reprobe eDP and LVDS connectors on hotplug event drm/i915: On fb alloc f...

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.

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

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

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

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