On 05.04.2018 13:51, Carsten Behling wrote: > > > > 2018-04-05 13:39 GMT+02:00 Laurent Pinchart > <laurent.pinchart@xxxxxxxxxxxxxxxx > <mailto:laurent.pinchart@xxxxxxxxxxxxxxxx>>: > > 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 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
