drm/bridge/synopsys: dsi: support for I2C connected bridges

drm/bridge/synopsys: dsi: support for I2C connected bridges

[Matt Redfearn]

[-- Attachment #1.1: Type: text/plain, Size: 1464 bytes --]

Hi,
I have looked through patchwork and recent messages to the dri-devel
mailing list, but since I am new to this area of the kernel I apologise if
I'm re-asking a question or if I have not understood how this is supposed
to work correctly.

I am looking at a device that has a Synopsis DW MIPI DSI controller
embedded. Externally, this is connected to a ADI ADV7533 I2C DSI -> HDMI
bridge. I am trying to write a glue driver for the embedded DSI host,
wrapping the common code in bridge/dw_mipi_dsi.

So far, the ADV7533 driver probes and registers itself as a a bridge
via drm_bridge_add(). However, my wrapper driver for the DW MIPI fails,
since it calls dw_mipi_dsi_probe -> __dw_mipi_dsi_probe
-> mipi_dsi_host_register. This then iterates over DT looking for the
connected device, as a child of the DSI device. Of course it does not find
one, since the connected device is a child of the I2C bus.

I see there has been various discussions related to the correct DT
hierarchy for these devices, and the consensus does appear to be that this
is correct - the bridge is controlled via I2C and so should be a child of
the I2C bus. However, how should the host device cope with this? It appears
that we should, perhaps, use OF graph with a ports{} node to describe the
data connection between the DSI host and it's child. Is this correct? Has
there been any efforts posted (I haven't found any) to support this in the
dw_mipi_dsi driver?

Thanks in advance,
Matt

[-- Attachment #1.2: Type: text/html, Size: 1770 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/bridge/synopsys: dsi: support for I2C connected bridges

[Laurent Pinchart]

Hi Matt,

On Monday, 1 October 2018 18:59:41 EEST Matt Redfearn wrote:
> Hi,
> I have looked through patchwork and recent messages to the dri-devel
> mailing list, but since I am new to this area of the kernel I apologise if
> I'm re-asking a question or if I have not understood how this is supposed
> to work correctly.

No need to apologize, and welcome to dri-devel :-)

> I am looking at a device that has a Synopsis DW MIPI DSI controller
> embedded. Externally, this is connected to a ADI ADV7533 I2C DSI -> HDMI
> bridge. I am trying to write a glue driver for the embedded DSI host,
> wrapping the common code in bridge/dw_mipi_dsi.
> 
> So far, the ADV7533 driver probes and registers itself as a a bridge
> via drm_bridge_add(). However, my wrapper driver for the DW MIPI fails,
> since it calls dw_mipi_dsi_probe -> __dw_mipi_dsi_probe
> -> mipi_dsi_host_register. This then iterates over DT looking for the
> connected device, as a child of the DSI device. Of course it does not find
> one, since the connected device is a child of the I2C bus.
> 
> I see there has been various discussions related to the correct DT
> hierarchy for these devices, and the consensus does appear to be that this
> is correct - the bridge is controlled via I2C and so should be a child of
> the I2C bus. However, how should the host device cope with this? It appears
> that we should, perhaps, use OF graph with a ports{} node to describe the
> data connection between the DSI host and it's child. Is this correct?

You have analyzed the problem very well, using OF graph is indeed (in my 
opinion at least) the correct method here.

> Has there been any efforts posted (I haven't found any) to support this in
> the dw_mipi_dsi driver?

Not to my knowledge, but I haven't followed the dw_mipi_dsi development, so I 
could be wrong.

-- 
Regards,

Laurent Pinchart



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel