On Tue, Jan 14, 2025 at 09:32:11PM +0900, Hector Martin wrote: > - On the DP/display side, we haven't implemented this yet, but in the > future the single "apple,display-subsystem" driver (which actually > provides the top-level DRM device for all the underlying discrete > display controllers, and is already its own virtual device in the DT) > will present virtual ports for the different PHYs, and handle the > muxing/assignment between them and the display controllers on its side > (there is potentially complex policy here too, since not all display > controllers are equal and there may be a need to reassign a display for > a lower-spec screen to a lower-spec display controller to free up a > higher-spec controller for a higher-spec screen, but we need a > controller assigned to a port to even read EDID to figure that out, so > it's going to be messy). Just on the DP/drm side I think the pieces are there, but might need some polish: - with drm_connector_helepr_funcs->detect_ctx and ->mode_valid_ctx you can temporarily steal a crtc for probing, and as long as you don't hold unrelated modeset locks userspace shouldn't notice. This goes back to crt/vga load detection where some hw needed drivers to light up a full crtc. There's also the entire drmGetConnector vs drmGetConnectorCurrent to avoid such potentially expensive probe steps and just reuse cached values. - if you can't get a crtc for probing there's the "unknown" connector status. We could perhaps sharpen the semantics of this (like officially documenting that reprobing with all other crtc switched off sometimes helps), but it's there. I'm also not super worried about this case because we don't have any available crtc anymore, so even if we can probe there's no way to light it up without disabling some other stuff. And as soon as you disable other stuff you can probe everything again (with the fixed locking of the ->detect/mode_valid_ctx callbacks) - for the crtc assignment issue there's either drivers virtualizing them, or userspace doing combinatorial probes. Personally I'm leaning towards drivers having to virtualize crtcs (and then you can peak the least one that works, which I think should sort this out), but it's an open and getting discussed in other areas (like having to steal crtc for dual-pipe outputs). We might get a proper documentation patch with an actual kernel/compositor api contract here. > But I'm not happy at all with the weird, load-bearing intermingling of > tipd/atcphy/dwc3 there. There's bound to be places where the > abstractions leak and we end up with more and more horrible workarounds, > or layering violations. > > A further question is how all this should be represented in the device > tree. That might drive the software architecture to a point, or vice versa. > > Any ideas? For the larger issue my only uninformed take is ... smells like too much midlayer. Like you'll certainly get some raised eyebrows if you submit a DP driver without using dp helpers since that's a proper standard. But if your hw has half the DP stack in firmware and just can't be smashed into the drm dp helpers we have then I think even that would make sense. Plus we already have like 3 different generations of dp helpers anyway, because getting helpers right is kinda hard. > Some further reading here: > https://social.treehouse.systems/@marcan/113821266231103150 I dropped some unstructured replies with the same stuff on there too first. Cheers, Sima -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
