> 2018-04-05 13:39 GMT+02:00 Laurent Pinchart < laurent.pinch...@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. Regards -Carsten
_______________________________________________ dri-devel mailing list email@example.com https://lists.freedesktop.org/mailman/listinfo/dri-devel