Hi Maxime,
On Thu, Mar 10, 2022 at 4:05 PM Maxime Ripard maxime@cerno.tech 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@amarulasolutions.com wrote:
or a Hi All,
On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki jagan@amarulasolutions.com wrote:
Hi Laurent,
On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart laurent.pinchart@ideasonboard.com 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
- MIPI Switch PI3WVR626
- Conventional Mux Switch
- 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.