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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
