Re: Fwd: DRM MIPI DSI device and I2C device?

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

 



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 ?

-- 
Regards,

Laurent Pinchart



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




[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