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