From: Simona Vetter <simona.vetter@ffwll.ch>
To: Hector Martin <marcan@marcan.st>
Cc: devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
linux-usb@vger.kernel.org, linux-embedded@vger.kernel.org,
Asahi Linux <asahi@lists.linux.dev>,
linux-arm-kernel@lists.infradead.org,
dri-devel@lists.freedesktop.org
Subject: Re: Unified Type C PHYs and top-level port management
Date: Tue, 14 Jan 2025 16:17:36 +0100 [thread overview]
Message-ID: <Z4aAEA6Kmc4R-Wlb@phenom.ffwll.local> (raw)
In-Reply-To: <fda8b831-1ffc-4087-8e7b-d97779b3ecc5@marcan.st>
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
next prev parent reply other threads:[~2025-01-14 15:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-14 12:32 Unified Type C PHYs and top-level port management Hector Martin
2025-01-14 15:17 ` Simona Vetter [this message]
2025-02-13 6:42 ` Peter Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z4aAEA6Kmc4R-Wlb@phenom.ffwll.local \
--to=simona.vetter@ffwll.ch \
--cc=asahi@lists.linux.dev \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=marcan@marcan.st \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).