Hi Maxime, On Thu, Mar 10, 2022 at 4:05 PM Maxime Ripard <maxime@xxxxxxxxxx> wrote: > > On Wed, Mar 09, 2022 at 06:45:10PM -0600, Adam Ford wrote: > > On Wed, Mar 9, 2022 at 1:11 PM Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > or a Hi All, > > > > > > On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > Hi Laurent, > > > > > > > > On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart > > > > <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > Hello, > > > > > > > > > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote: > > > > > > Hi, > > > > > > > > > > > > Removed my invalid email (I will update files next week). > > > > > > > > > > > > On 08.10.2021 13:14, Jagan Teki wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I think this seems to be a known use case for industrial these days with i.mx8m. > > > > > > > > > > > > > > The host DSI would configure with two bridges one for DSI to LVDS > > > > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we > > > > > > > can use only one bridge at a time as host DSI support single out port. > > > > > > > So we can have two separate device tree files for LVDS and HDMI and > > > > > > > load them static. > > > > > > > > > > > > > > But, one of the use cases is to support both of them in single dts, and > > > > > > > - Turn On LVDS (default) > > > > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in > > > > > > > > > > > > Are you sure it will work from hardware PoV? Do you have some demuxer? > > > > > > isolation of pins? > > > > > > > > > > It may be in the category of "you shouldn't do this, but it actually > > > > > works". I've seen the same being done with two CSI-2 camera sensors > > > > > connected to the same receiver, with one of them being held in reset at > > > > > all times. > > > > > > > > Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2 > > > > input data lanes and 1 clock lane from SoC and produces 4 data lanes > > > > and 2 clock lanes and from switch output 2 lanes and 1 clock are > > > > inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to > > > > LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to > > > > HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to > > > > LVDS. > > > > > > > > However, routing of these lanes are controlled by SEL, OE GPIO pins. > > > > So at a time we can access only single bridge. > > > > > > > > > > > > > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design. > > > > > > > > > > > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on > > > > > > > port 2 in the DSI host node, and trying to attach the respective > > > > > > > bridge based on HDMI-INT like repeating the bridge attachment cycle > > > > > > > based on the HDMI-INT. > > > > > > > > > > > > I think more appropriate would be to share the same port, but provide > > > > > > two endpoints inside this port - we have two hardware sharing the same > > > > > > physical port. > > > > > > > > > > That sounds like the correct DT description to me. > > > > > > > > > > > > Can it be possible to do bridge attachment at runtime? something like > > > > > > > a bridge hotplug event? or any other possible solutions? > > > > > > > > > > > > > > Any suggestions? > > > > > > > > > > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi + > > > > > > some toshiba bridge - panel and bridge are dynamically 'plugged' and > > > > > > 'unplugged' from exynos_drm, but they do not use bridge chain for this > > > > > > and some other reasons. (un|re|)plugging should be performed of course > > > > > > when pipeline is off (connector disconnected). I am not sure about > > > > > > bridges added to bridge chain - you need to inspect all opses to ensure > > > > > > it can be done safely. > > > > > > > > > > > > And the main issue: Daniel does not like it :) > > > > > > > > > > Neither do I :-) Could it be handled with two DRM connectors that are > > > > > mutually exclusive ? > > > > > > > > How about adding lvds-connector, hdmi-connector on the pipeline and > > > > select them based on the switch SEL GPIO? does it make sense to do > > > > this implementation via display-connector.c > > > > > > I have somehow managed to make runtime switching possible between LVDS > > > and HDMI with the help of DRM bridges. > > > > > > | => ADV7535 => > > > HDMI-A Connector > > > DSI Host => display-switch => | > > > |=> SN65DSI83 => Panel-Simple > > > > > > display-switch here is a bridge driver that can switch or attach the > > > downstream bridge flow based on HDMI HPD here. One potential problem > > > is that when we switch from LVDS to HDMI Out the HDMI Out is displayed > > > with the resolution that LVDS has and it is unable to display higher > > > HDMI resolutions even though it supports it. Does anyone aware of > > > changing the resolution at runtime, please let me know? > > > > > > Technically, the display-switch hardware does available in various forms > > > 1. MIPI Switch PI3WVR626 > > > 2. Conventional Mux Switch > > > 3. Converter bridge DSI to LVDS/HDMI (from Lontium). > > > > > > Overall I believe this can be a potential possible feature and good to > > > support on Mainline as the hardware is intended to design for it. > > > > > > Any thoughts on this please let me know? > > > > I wonder if it would be possible to trigger a hot plug event similar > > to what is done when an HDMI cable is inserted/disconnected. > > > > If one switches, force a disconnect event, then triggle the connection > > event to force the video system to rescan/attach. I am not sure how to > > go about implementing such a thing, but that's my first thought > > Nothing prevents the DRM Master to just ignore the hotplug event though :) > Kodi does that for example. > > I think we could simply create two connectors, one for LVDS, one for > HDMI, with atomic_check making sure only one of them is enabled at the > same time? > > The one thing that would make it difficult is that we're changing the > bridge list to a tree. For example, in such a case, what should > drm_bridge_get_next_bridge return? This will obviously depend on the > state, but it's used in context were we don't have a state (such as > drm_bridge_connector_init). >From display-switch bridge, we can have a tree of one bridge chain for HDMI and another bridge chain for LVDS ended with respective connectors but how to attach the respective down-stream bridges of the tree and get the associated connector? does "state" in the above mean to preserve each bridge chain path in order to get the proper connector? I tried to attach the down-stream bridge one after another in for loop from display-switch. Both attached and last bridge in the loop get enabled with LVDS-1 and HDMI-A-1 connectors are created but the last bridge chain is tailed with the first, not like the tree - like display-switch => lvds bridge => hdmi bridg. Any suggestions? Jagan.
