On Tue, Apr 11, 2023 at 1:17 PM Alexander Stein <alexander.stein@xxxxxxxxxxxxxxx> wrote: > > Am Donnerstag, 6. April 2023, 11:55:52 CEST schrieb Jagan Teki: > > [Replying the Daniel thread since he included bridge maintainers] > > > > On Thu, Apr 6, 2023 at 2:07 PM Daniel Vetter <daniel@xxxxxxxx> wrote: > > > Adding the usual bridge maintainer/review folks since this looks tricky. > > > -Daniel > > > > > > On Thu, 6 Apr 2023 at 10:33, Alexander Stein > > > > > > <alexander.stein@xxxxxxxxxxxxxxx> wrote: > > > > Hi Jagan, > > > > > > > > thanks for your reply. > > > > > > > > Am Mittwoch, 5. April 2023, 16:39:07 CEST schrieb Jagan Teki: > > > > > On Wed, Apr 5, 2023 at 7:39 PM Alexander Stein > > > > > > > > > > <alexander.stein@xxxxxxxxxxxxxxx> wrote: > > > > > > Hi, > > > > > > > > > > > > my platform has a DIP switch controlled multiplexer for MIPI DSI > > > > > > output > > > > > > signals. One output has a TI SN65DSI84 (LVDS) and the other output > > > > > > has a > > > > > > TI > > > > > > SN65DSI86 (eDP) attached to it. The Multiplexer status can be read > > > > > > back > > > > > > from a GPIO. The GPIO is also IRQ capable, so it would be possible > > > > > > to > > > > > > support hotplug additionally later on. > > > > > > > > > > I have this requirement a year back [1] but my design has i.mx8mq DSI > > > > > outputs to SN65DSI84(LVDS) and ADV7533 (HDMI) and GPIO has muxed as > > > > > IRQ in order to find the bridge selection. (not confused with HDMI > > > > > HPD). > > > > > > > > Looks quite similar. This platform can be used using imx8mq, imx8mm or > > > > im8xmn. That mentioned GPIO is also not the HDMI HPD, but connected to > > > > a DIP switch on the mainboard to be changed manually. > > > > So, you need to manually adjust the switch and boot the required > > output and the state of the output depends on the set switch gpios > > isn't it? do you need to set any gpio so that the required output will > > select? > > That's correct. There is no GPIO I need to set by software for the outputs > (despite the enable GPIO on the DSI-to-X bridges, but this is handled in their > appropriate drivers). If we don't do any gpio handling in mux-bridge then why do we need mux-bridge? what exactly is the job of the mux-bridge driver? > > > > > > > My initial idea was to create a DRM multiplexer bridge driver which > > > > > > (depending on the input GPIO) allows only one output to be enabled. > > > > > > Unfortunately ti- sn65dsi86.c driver expects a DSI host on remote > > > > > > node 0 > > > > > > (see ti_sn_attach_host and ti_sn_bridge_parse_dsi_host), so it does > > > > > > not > > > > > > work. ti-sn65dsi83.c just requires a drm_bridge. > > > > > > > > > > Yes, we need to have a finite amount of pipeline changes. assuming > > > > > that your mux bridge sits between DSI to Output interfaces the > > > > > proposed mux bridge selects which pipeline. > > > > > > > > My setup looks like this, but the switch is a different one than yours. > > > > > > > > | => SN54DSI86 => DP Connector > > > > > > > > DSI Host => display-switch => | > > > > > > > > | => SN65DSI83 => Panel-Simple > > > > This looks correct to me, as I designed the similar one. > > > > > > > > What is the best approach for this? I currently see two approaches: > > > > > > * Create an explicit DSI/DRM multiplexer bridge driver which > > > > > > registers > > > > > > itself as DSI host > > > > > > * Create a DRM multiplexer bridge (only). But this needs to remove > > > > > > the DSI > > > > > > device registration from ti-sn65dsi86.c > > > > > > > > > > Based on my experience, having a muxed bridge between in and out would > > > > > be proper in order to satisfy the pipeline as well as the design. That > > > > > mux bridge has to be a normal bridge doesn't aware of DSI or any other > > > > > interface like one of the submissions has done in the recent mailing > > > > > list. [2] Things would be complicated when we switch the outputs but > > > > > we still use normal static switching of outputs in a proper way. > > > > > > > > > > > I am aware that DSI support is suboptimal, so I'm not sure which > > > > > > approach > > > > > > on the TI bridge drivers is the correct one and needs to be > > > > > > considered as > > > > > > given. Any ideas? > > > > > > > > > > I did implement some complicated things of switching outputs at > > > > > runtime but the idea of the switching pipelines would be similar if > > > > > you want to implement it in a normal static way. Here are some details > > > > > and a demo of how those been worked. [3] [4] > > > > > > > > Thanks for the links. From what I read in those discussions dynamically > > > > (re)building the bridge chains it not correct/acceptable. Instead two > > > > bridges shall be created, but only one connector at the end shall be > > > > enabled. This> > > > > > would look like this: > > > > switched-bridge > > > > > > > > +------------+ +-------------+ > > > > > > > > | drm_bridge-|- next_bridge -- | LVDS bridge |- connector > > > > | > > > > | | +-------------+ > > > > > > > > in -| | > > > > > > > > | | +-------------+ > > > > | > > > > | drm_bridge-|- next_bridge -- | eDP bridge |- connector > > > > > > > > +------------+ +-------------+ > > > > > > > > ^ > > > > > > > > DIP switch > > > > > > > > But here I'm not so sure how an (hotplug) event (e.g. IRQ) on the > > > > switched- > > > > bridge can be forwarded to the connectors. But this hotplug event seems > > > > to be essential so that DRM master can reconfigure it's output. > > > > In my opinion, the switched-bridge needs to focus on switching the > > outputs based on DIP gpios, and hotplug events need to handle the > > associated display bridges like DP, HDMI, etc. It is possible for the > > switched-bridge to route the output displays without the hot plug. > > I agree, IMHO hotplug/HPD events is related to downstream connectors. > > > Assume the switched-bridge has port 1 and ep 0 connected to LVDS and > > port 1 and ep 1 connected to DP. then find and attach them at the > > bridge attach function. and do the necessary gpio enablements in > > enable or pre_enables. > > Ah nice. My initial idea was: > * port 0 ep 0: input > * port 1 ep 0: LVDS > * port 2 ep 0: DP > > But using two endpoints in one port looks neat. Although I'm not sure if there > is an actual difference. This is also possible but sometimes port 1 with ep 0, 1 means we pipeline offers 2 outputs but one at a time. > But if the GPIO check is only done in enable/pre_enable there is no way to > support changing the DIP switch aka switched-bridge at runtime. There is > nothing the hotplug (non-HPD) event can be sent to, no? The idea here is to change the bridge chain and this can be done in static via dt or runtime. In your case the state of the DIP-switch resembles desired output, correct? if so if we read that state at run-time, find the output, and attach that particular bridge chain. Fo dt case of showing output read the dt about the output state and attach the bridge chain accordingly. Thanks, Jagan.
