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. > > > > 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 > > > > 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. > > Best regards, > Alexander > > > [1] > > https://lore.kernel.org/all/CAMty3ZD7eFi4o7ZXNtjShoLd5yj3wn85Fm6ZNL89=QpWj4 > > 4KPw@xxxxxxxxxxxxxx/T/ [2] > > https://patchwork.kernel.org/project/dri-devel/patch/20230218111712.2380225 > > -6-treapking@xxxxxxxxxxxx/ [3] > > https://indico.freedesktop.org/event/2/contributions/76/ > > [4] https://www.youtube.com/watch?v=PoYdP9fPn-4&t=624s > > > > Thanks, > > Jagan. > > > -- > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany > Amtsgericht München, HRB 105018 > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider > http://www.tq-group.com/ > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
