[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support

[Tomi Valkeinen]

On 2013-12-06 14:54, Thierry Reding wrote:
> On Thu, Dec 05, 2013 at 04:37:39PM +0200, Tomi Valkeinen wrote:
>> On 2013-11-27 12:54, Thierry Reding wrote:
>>
>>>> I am not sure about hardwiring devices to virtual channels.
>>>> There could be devices which uses more than one virtual channel,
>>>> in fact exynos-drm docs suggests that such hardware exists.
>>>
>>> In that case, why not make them two logically separate devices within
>>> the kernel. We need the channel number so that the device can be
>>> addressed in the first place, so I don't see what's wrong with using
>>> that number in the device's name.
>>>
>>> The whole point of this patch is to add MIPI DSI bus infrastructure, and
>>> the virtual channel is one of the fundamental aspects of that bus, so I
>>> think we need to make it an integral part of the implementation.
>>
>> (I speak here more in the context of OMAP display subsystem and CDF, and
>> this might not be totally applicable to DRM).
>>
>> In my opinion, DSI shouldn't be though of in the same way as other buses.
>>
>> In most of the cases, there's just one DSI peripheral connected. This
>> peripheral may answer to multiple DSI VC IDs, though. I don't like the
>> idea of having to split one device driver into multiple drivers, just to
>> manage multiple DSI VC IDs.
> 
> If they respond to multiple VCs, then I suppose they would be logically
> separate devices, even if only a single physical device. What would be
> the point of addressing them individually if they are just the same
> device?

No idea. But I have worked with a device, that used VC0 for the device's
configuration registers, VC1 for buffer commands (the device had a
framebuffer), VC2 and VC3 for panels connected to that device.

Of course, that kind of devices are probably (?) rare, so it may not be
a big issue.

>> In some rare cases (I've never seen one in production) there may be a
>> DSI hub, and one or two DSI peripherals behind it. But the hub is not
>> really a hub, but a router, and the router requires configuration. The
>> case here is not really one DSI bus with two or more peripherals, but
>> two or more independent 1-to-1 DSI buses.
> 
> From the CPUs perspective there's still only one bus. Or perhaps to put
> it another way, there is a single address space, because that's what's
> implied by how the virtual channel number is defined.
> 
> So you would still represent the DSI hub as one device with a specific
> VC and the two peripherals behind it with different VC numbers. The VC
> number space simply doesn't allow much else to be done.
> 
>> I have never seen a pure hub, i.e. something that would just
>> forward/broadcast the DSI packet to two or more DSI peripherals.
>>
>> So I think we should consider DSI as a one-to-one link, and let the DSI
>> peripheral manage the VC IDs as it wants.
> 
> But doing so would prevent us from supporting setups where we have two
> separate peripherals with different VC numbers.

No it wouldn't. We could still communicate with the extra peripherals
via the hub device. What I was trying to say is that we shouldn't think
or model DSI with multiple devices as multiple devices connected to the
same DSI bus. Instead, it should be seen as a tree of one-to-one links
(as it is in the HW).

For the sake of discussion, let's consider a simple DSI hub setup:

SoC DSI -> DSI Hub -> DSI panel 1
                   -> DSI panel 2

The hub would use, say VC0 for hub configuration, and it'd route VC2 to
panel 1 and VC3 to panel2. Both panels would use VC0, so the hub would
translate the VC ID accordingly.

How would you represent this in Linux? How about the case where the DSI
hub uses i2c for control (DSI used only for video data), and the
messages to DSI panels are sent via i2c?

>> I don't see any benefit in trying to create a similar linux bus for
>> DSI as we have for, say, i2c or spi.
> 
>>> Without that fixed virtual channel number we can't use the device in the
>>> first place. How are you going to address the device if you don't know
>>> its virtual channel?
>>
>> The DSI peripheral driver must know the VC IDs. Often they are hardcoded
>> values, and they can be defined in the driver code.
> 
> When you say "often", can you make a guarantee that it will always be
> the case? I don't think so. I can easily imagine somebody making the VC
> configurable via straps, which would come in handy if you wanted to use
> the same IC multiple times within the same design.

Of course I can't guarantee things like that. But I have never seen a
DSI device that can be configured in such a way. Have you?

> In that case you still need some way to specify the VC on a per-board
> basis, either in DT or "platform data".

I'm not saying we should prevent that kind of device from working. But
if all the known devices use a fixed VC ID scheme, maybe there's not
much point in requiring to enter the VC ID manually in all the dts
files. If there's a device with configurable VC ID, it can still be
supported by custom DT properties.

>> I don't see why the DSI host driver would need to know the VC IDs, as
>> it can't really do anything independently with the peripheral anyway.
>> All the transactions should be started by the DSI peripheral driver.
> 
> There are things that are standardized in DSI. The core could for
> instance try to probe peripherals by reading the DDB.

That's not part of DSI. It's part of DCS. Not all devices support DCS,
or they may support only some parts of it. Also the devices usually need
regulator setup, resetting via gpios, or other similar setup which makes
automatic probing not an option.

> But even that aside, we'll still need some way to store a device's VC
> number somewhere. Even if the DSI host doesn't have any explicit
> knowledge about it, you still need to pass it along when you want to
> send a message to a device. So when you start a transaction from within
> a device driver, you still need to get the VC number from somewhere.

Yep.

> The proposal is to store that number in struct mipi_dsi_device. It's a
> logical choice because it is something that characterises a device. It
> is also a property of every device, so by storing it within a common
> structure gives drivers a standard way of accessing it instead of having
> each driver come up with it's own way to store it.

Yep, that sounds fine to me if mipi_dsi_device is not a linux device
(but it is in this patch).

I'll try to summarize my view on mipi dsi:

DSI is a video bus. It can be used for control, but it's main purpose is
as a video data bus. Video has rather strict timing requirements, which
means control messages have to be done in a controlled manner.

DSI devices quite often have another control bus, usually i2c. I guess
the reason to support i2c in addition to DSI is the timing restrictions
on the DSI control bus. If the DSI device is represented as a linux DSI
device on a linux DSI bus, supporting the i2c is difficult.

It is possible to have multiple DSI devices behind a single DSI
connection, but it is not a generic solution, and requires one to use
the DSI peripherals in a very controlled manner to make sure no DSI
device is blocking the other ones for too long. I have not seen these in
production, and while I'm just guessing, the reason may be that is so
difficult to make them work well.

The only standard part of DSI, in my experience, is the DSI packet layer
(maybe there's a better term for it). Anything else is often custom. For
this reason I think the DSI peripheral driver has to be in full control
of the device, and the DSI bus cannot really do anything by itself.

There's not much "bus" in DSI in my opinion. No probing, one-to-one
links, very limited "address space", all the cases I know have just one
DSI device...

So... While having a Linux DSI bus, etc. would feel elegant and nice, I
just feel it's not easy and not worth it.

What we have in omapdss is far from perfect, but it has been working
quite nicely. DSI is considered just as a data bus, with extra
functionality for sending control messages. A DSI device is either a
platform device if it requires no control or the control is done via
DSI, or it's a device of the control bus like i2c.

All that said, I may be mentally stuck in the old models I've been using
for a long time, so maybe a different approach for DSI is good. We just
need to make sure the existing devices can be supported.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131209/26b5c8a2/attachment-0001.pgp>