Fwd: DRM MIPI DSI device and I2C device?

[Andrzej Hajda]

On 05.04.2018 13:51, Carsten Behling wrote:
>
>
> > 2018-04-05 13:39 GMT+02:00 Laurent Pinchart
> <laurent.pinchart at ideasonboard.com
> <mailto:laurent.pinchart at ideasonboard.com>>:
> > Hi Andrzej,
> >
> > On Thursday, 5 April 2018 14:28:51 EEST Andrzej Hajda wrote:
> >> On 05.04.2018 12:28, Laurent Pinchart wrote:
> >>> On Wednesday, 4 April 2018 11:41:05 EEST Carsten Behling wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I would like to write a DRM bridge driver that is an I2C device and a
> >>>>> DRM MIPI DSI device.
> >>>>>
> >>>>> It looks like that both - 'i2c-core.c: of_i2c_register_devices' and
> >>>>> 'drm_mipi_dsi.c: mipi_dsi_host_register'  are registering their devices
> >>>>> by iterating over devicetree child nodes with
> >>>>> for_each_available_child_of_node.
> >>>>>
> >>>>>> Since I can't make the bridge a child node of both, I don't know how to
> >>>>> resolve it.
> >>>>
> >>>> Found the answer myself. adv7533 driver is a good example. Devicetree
> >>>> exists for qcom apq8016-sbc. No need to make the bridge a MIPI DSI child
> >>>> node.
> >>>
> >>> This is an issue that has largely been ignored so far in Linux. Both DT
> >>> and the Linux kernel device model organize devices in a tree structure
> >>> based on the control buses. Devices that are connected to multiple
> control
> >>> buses haven't been taken into account in the design and are thus hard to
> >>> support.
> >>>
> >>> As you may know, DSI can work in command mode or data mode. In data mode
> >>> the DSI bus is only use to transfer video data, while in command mode it
> >>> is also used to control the device (reading and writing registers).
> >>
> >> I am not sure what you mean by data and command mode. MIPI DSI specs
> >> says about video and command mode - modes to transfer video data. In
> >> both cases DSI can be used to control the device.
> >
> > Sorry, I meant pure video mode, when a panel only uses DSI to
> receive video
> > data but handles all control communication through a separate
> control bus.
> >
> >>> A DSI device operating in data mode and controlled through I2C isn't a
> >>> problem, as there's a single control bus in that case. The device
> should
> >>> be a child of the I2C controller in DT, and will be instantiated
> through
> >>> of_i2c_register_devices(). A DSI device operating in command mode
> without
> >>> any other control bus isn't a problem either, it will be a child
> of the
> >>> DSI master in DT, and will bee instantiated through
> >>> mipi_dsi_host_register().
> >>>
> >>> A DSI device operating in command mode that also require configuration
> >>> through a separate control bus (such as I2C, but also SPI) is much
> more
> >>> problematic to support. Fortunately those devices are rare. Hopefully
> >>> your device won't fall in this category. If it does, we can
> discuss how
> >>> to best support it.
> >>
> >> As you have already found adv bridge is a good example. It is not clear
> >> from the emails if DSI is used only to send video, or also to control?
> >> And if to control, is it used to pass only specific commands
> >> or can be used as alternative to i2c interface?
> >
> >Carsten, could you please provide more information about the panel you're
> >using ?
>
> Sure, it's an TI SN65DSI84. It is just receiving pixel data on the
> input lines.
> I got an incomplete driver from Variscite that just writes a
> hardcoded  I2C regmap from
> DTS. I'm currently writing a real DRM bridge driver based on that. I
> didn't find
> a better one.

According to datasheet it looks like i2c controlled only DSI bridge, so
adv driver should be a good reference.

Regards
Andrzej

>
> Regards
> -Carsten
>