Re: DSI Bridge switching

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).

Maxime

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux