Re: MIPI DSI, DBI, and tinydrm drivers

[Paul Cercueil <paul@crapouillou.net>]

Le dim. 24 mai 2020 à 23:24, Noralf Trønnes <noralf@tronnes.org> a 
écrit :
> 
> 
> Den 24.05.2020 22.42, skrev Paul Cercueil:
>> 
>> 
>>  Le dim. 24 mai 2020 à 22:14, Noralf Trønnes <noralf@tronnes.org> 
>> a écrit :
>>> 
>>> 
>>>  Den 24.05.2020 21.54, skrev Paul Cercueil:
>>>>   Hi Noralf,
>>>> 
>>>>   Le dim. 24 mai 2020 à 19:46, Noralf Trønnes 
>>>> <noralf@tronnes.org> a
>>>>  écrit :
>>>>> 
>>>>> 
>>>>>   Den 24.05.2020 18.13, skrev Paul Cercueil:
>>>>>>    Hi list,
>>>>>> 
>>>>>>    I'd like to open a discussion about the current support of 
>>>>>> MIPI
>>>>>>  DSI and
>>>>>>    DBI panels.
>>>>>> 
>>>>>>    Both are standards from the MIPI alliance, both are 
>>>>>> communication
>>>>>>    protocols between a LCD controller and a LCD panel, they
>>>>>>  generally both
>>>>>>    use the same commands (DCS), the main difference is that DSI 
>>>>>> is
>>>>>>  serial
>>>>>>    and DBI is generally parallel.
>>>>>> 
>>>>>>    In the kernel right now, DSI is pretty well implemented. All 
>>>>>> the
>>>>>>    infrastucture to register a DSI host, DSI device etc. is 
>>>>>> there. DSI
>>>>>>    panels are implemented as regular drm_panel instances, and 
>>>>>> their
>>>>>>   drivers
>>>>>>    go through the DSI API to communicate with the panel, which 
>>>>>> makes
>>>>>>  them
>>>>>>    independent of the DSI host driver.
>>>>>> 
>>>>>>    DBI, on the other hand, does not have any of this. All (?) DBI
>>>>>>  panels
>>>>>>    are implemented as tinydrm drivers, which make them 
>>>>>> impossible to
>>>>>>  use
>>>>>>    with regular DRM drivers. Writing a standard drm_panel driver 
>>>>>> is
>>>>>>    impossible, as there is no concept of host and device. All 
>>>>>> these
>>>>>>   tinydrm
>>>>>>    drivers register their own DBI host as they all do DBI over 
>>>>>> SPI.
>>>>>> 
>>>>>>    I think this needs a good cleanup. Given that DSI and DBI are 
>>>>>> so
>>>>>>    similar, it would probably make sense to fuse DBI support 
>>>>>> into the
>>>>>>    current DSI code, as trying to update DBI would result in a 
>>>>>> lot
>>>>>>  of code
>>>>>>    being duplicated. With the proper host/device registration 
>>>>>> mechanism
>>>>>>    from DSI code, it would be possible to turn most of the 
>>>>>> tinydrm
>>>>>>  drivers
>>>>>>    into regular drm_panel drivers.
>>>>>> 
>>>>>>    The problem then is that these should still be available as 
>>>>>> tinydrm
>>>>>>    drivers. If the DSI/DBI panels can somehow register a 
>>>>>> .update_fb()
>>>>>>    callback, it would make it possible to have a panel-agnostic 
>>>>>> tinydrm
>>>>>>    driver, which would then probably open a lot of doors, and 
>>>>>> help a
>>>>>>   lot to
>>>>>>    clean the mess.
>>>>>> 
>>>>>>    I think I can help with that, I just need some guidance - I am
>>>>>>  fishing
>>>>>>    in exotic seas here.
>>>>>> 
>>>>>>    Thoughts, comments, are very welcome.
>>>>> 
>>>>>   I did look at this a few months back:
>>>>> 
>>>>>   drm/mipi-dbi: Support panel drivers
>>>>> 
>>>>>  
>>>>> https://lists.freedesktop.org/archives/dri-devel/2019-August/228966.html
>>>>> 
>>>>> 
>>>>>   The problem with DBI is that it has reused other busses which 
>>>>> means we
>>>>>   don't have DBI drivers, we have SPI drivers instead (6800/8080 
>>>>> is not
>>>>>   avail. as busses in Linux yet). DSI and DPI on the other hand 
>>>>> has
>>>>>   dedicated hw controller drivers not shared with other 
>>>>> subsystems.
>>>> 
>>>>   I don't think that should be much of a problem. You could have a
>>>>  DBI/SPI
>>>>   bridge, that wraps a SPI device into a DBI host, for instance. 
>>>> The
>>>>  panel
>>>>   drivers would just use the DBI API without having to know what's 
>>>> done
>>>>   behind the scene.
>>> 
>>>  This will be a bridge implemented in software, are we allowed to 
>>> have
>>>  software devices in the Device Tree? I though it was just allowed 
>>> to
>>>  describe hardware.
>> 
>>  It wouldn't appear in devicetree. If the panel is connected over 
>> SPI,
>>  then DBI is just the protocol it uses.
> 
> How do you attach a panel to the DBI device if it doesn't appear in 
> DT?

When probed from a DBI host controller, the panel's devicetree binding 
would look like this:

&dbi_host {

    panel {
        compatible = "my,dbi-device";
    };
};

When probed from SPI it would appear in DT like this:

&spi {

    panel@0 {
        reg = <0>;
        compatible = "my,dbi-device-spi";
    };
};

In that case, the driver would create a SPI-DBI bridge, but that is an 
implementation detail that doesn't belong in devicetree.


> Another problem is that the DBI panel uses SPI both for framebuffer
> upload and controller initialization. How shall this be handled when 
> the
> panel driver needs SPI for init and the DBI bridge needs SPI for frame
> upload?

Does the panel driver need SPI for init? I don't think so. It needs to 
send DBI commands over SPI, yes. Only the DBI-SPI bridge would control 
the SPI device.

-Paul

>> 
>>  If probed as a SPI device driver, the panel's spi_driver would 
>> register
>>  an instance of the DBI/SPI host driver, then register itself as a
>>  dbi_driver. If probed from a DBI host it would just register itself 
>> as a
>>  dbi_driver.
>> 
>>  -Paul
>> 
>>>> 
>>>>>   My initial tinydrm work used drm_panel, but I was not allowed to
>>>>>  use it
>>>>>   (at least not the way I had done it).
>>>>> 
>>>>>   Noralf.
>>>>> 
>>>>>> 
>>>>>>    Cheers,
>>>>>>    -Paul
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> 


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