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

[Tomi Valkeinen]

On 2013-12-09 15:10, Thierry Reding wrote:

>> 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.
> 
> Well, VC2 and VC3 certainly sound like logically separate devices to me.
> If they are only connected to the device it sounds like they aren't part
> of the device at all.

Yes, the two panels are obviously separate devices.

> One could even argue that a device's configuration and the framebuffer
> are logically separate and therefore it wouldn't be a problem to address
> them as separate devices.

True. But one could also argue that handling them with separate linux
devices just causes unnecessary complexity.

>>>> 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).
> 
> But even if you have a tree of one-to-one links, you still need some way
> to address the individual nodes in the tree. The VC ID is the only way
> by which you can address a node. I don't see how you can possible send
> packets to more than one node if you keep sending packets to the same
> address. Where does the missing information magically come from?

From the DSI hub.

In the example case below, let's say the DSI panel 1 driver is told to
send a configuration packet to the panel. The panel driver would call a
dsi_transmit op, giving as arguments the VC number 0, and the packet data.

That call would go to the DSI hub driver. It knows how it routes the
packets (the routing configuration is either hardcoded or passed via DT
data), and then calls dsi_transmit op on SoC DSI, with VC number 2 and
the packet data.

>> 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?
> 
> You keep saying that devices use various VC IDs (VC0 for hub config, VC2
> and VC3 for panels 1 and 2 in this case). But those are exactly the
> addresses. You've got to have some way within the kernel to store those.
> 
> Given the limited address space of DSI there's no way to accurately
> represent the hierarchy of the above in the bus/device numbering. But
> that doesn't mean you can't assign addresses (VC IDs) to the devices. In
> fact you've given examples yourself.

Yes, but I guess the difference in our views is that I see the VC IDs as
"link local" and routing is done by the hubs as they see fit. In other
words, if I'm not mistaken, you'd have a Linux DSI bus with three
devices in the bus, each having its own VC ID, whereas I'd have a DSI
"link" between the SoC and the hub, without any general information
about the VC IDs used, and two additional DSI links, from the DSI hub to
each panel.

>> 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?
> 
> Well you still have to send the video data somewhere, right? Each video
> packet still has a destination VC ID, independent of whether that same
> bus is used for configuration or not.

Yes, sure. And actually the DSI could also be used for control, in
addition to i2c. DSI is much faster, so it could be used to send tables
or such, but i2c would be used later for backlight and other similar
adjustments.

> Of course it's more difficult to represent these devices than if they
> were accessed using only a single bus. Perhaps it could help to look at
> Linux devices not so much as the equivalent of a physical device, but
> rather as a representation of the logical functionality of that device.
> 
> In your example above, the DSI hub would be a single physical device.
> But it also has two logically separate functions. It can be configured
> and it passes through video to one or more panels. Similarily for the
> panels, where each has an I2C control input and a DSI video input.
> 
> The I2C portion can be a device separate from the DSI portion. That way
> your problem becomes one of interconnecting two "devices". You could for
> instance pass a handle to the control portion to the DSI portion and let
> the driver for that handle control via I2C. In DT terms that would be
> something like this:
> 
> 	i2c {
> 		dsihub: dsi-hub at 2f {
> 		};
> 
> 		panel1: panel at 30 {
> 		};
> 
> 		panel2: panel at 31 {
> 		};
> 	};
> 
> 	dsi {
> 		hub at 0 {
> 			control = <&dsihub>;
> 		};
> 
> 		panel at 2 {
> 			control = <&panel1>;
> 		};
> 
> 		panel at 3 {
> 			control = <&panel2>;
> 		};
> 	};

Hmm, well.

The panels here should should be inside the hub node for DSI case. They
are connected to the hub, not the SoC's DSI, and need the hub to be
powered up and configured to work. And the hub should contain two output
DSI busses, each having one panel with VC ID 0. Probably something like:

dsi {
	hub at 0 {
		dsi at 0 {
			panel at 0 {
			};
		};

		dsi at 1 {
			panel at 0 {
			};
		};
	};
};

That kind of ruins the idea of representing the panels as DSI devices
with VC IDs of 2 and 3. I don't know how that should be managed then...

But this DT example shows how DSI is really a one-to-one bus in the
hardware.

>>>> 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?
> 
> I've seen plenty of I2C devices that do so. The reason is usually so
> that the same IC can be used on the same bus multiple times. Why would
> DSI be any different? If in your example above, panel 1 and panel 2 are
> identical panels, they would use the same hardcoded VC IDs, right? So
> you couldn't address them separately. In such a case, if I were the
> panel vendor I'd make the VC ID selectable (via straps for example).

With DSI you always have a hub, which can translate the addresses. With
my example above, both panels are identical and they have the same VC ID
of 0.

> No, I've never seen a DSI device like it. But I still think that we
> should be prepared, especially if it doesn't add any significant
> overhead. Every other bus with potentially multiple peripheral needs
> addressing and so does DSI. Why wouldn't we want to associate that
> address with a device on that bus?
>
>>> 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.
> 
> But we loose any possibility of ever making that code generic. Even if
> the DSI specification doesn't go into the details (it even explicitly
> chickens out at that point), it still defines that each DSI bus can have
> up to 4 peripherals. So by definition the 2 bit VC is something that
> every DSI host and every DSI peripheral needs to support. There is no
> reason to represent it using custom properties. It is completely
> generic.

Well, afaik, the VC ID is really just data in the packet. There's
nothing for the HW to support. I mean, the DSI host hardware doesn't
need to understand anything about the VC ID. This is the case on OMAP,
the hardware has no configuration related to the VC ID. Maybe other
hardware does.

Of course, that's no reason not to make VC handling generic if it makes
sense otherwise to do so.

>>> 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).
> 
> What's that got to do with anything?

See below. A linux device implies a Linux DSI bus, and I don't agree
that having a DSI bus is a good thing.

>> 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.
> 
> The same is true of the reverse. If the DSI device is represented as a
> Linux I2C device on a Linux I2C bus, supporting the DSI is difficult.
> That's just something we have to deal with.

No it's not, if DSI is not considered as a full blown control bus, but
just a data bus.

We (omapdss and CDF at least) anyway need a method to deal with the
video data paths. I.e. define that this component outputs video data
which goes to that component, and have some kind of API to control that
particular part of the whole video pipeline. So we have that for DSI,
and if the DSI panel is controlled via i2c, the i2c device can easily
use that "video data API" to manage the DSI side.

>> 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.
> 
> The same is true of I2C. There's no probing or standard registers across
> devices. But it's still a bus that can have multiple peripherals and a
> way to address them. Every peripheral has an associated device, which
> drivers can use to have the I2C master send messages to the correct
> peripheral.

Right, but with i2c, the all the devices are actually connected to the
host. That is not the case with DSI.

It is normal to have multiple i2c devices on a bus. It's rare (never
seen such) to have multiple DSI devices behind one DSI connector.

>> There's not much "bus" in DSI in my opinion. No probing, one-to-one
>> links,
> 
> There are one-to-many links as well. You've in fact provided an example
> of one such device above to prove another point.

No, my example has three one-to-one links. The physical DSI buses are
always one-to-one. Maybe we could represent DSI as both a physical
one-to-one link tree, matching the hardware, and a logical bus, matching
how it's used.

But that starts to sound horribly complex for a one-to-one video bus,
when all the known boards have just a single DSI device, and supporting
multiple devices would be very tricky in any case.

>> very limited "address space", all the cases I know have just one
>> DSI device...
> 
> Most of that's true for I2C or SPI as well. SPI even needs sideband
> signalling to address more than a single slave.

At least the i2c address space is huge compared to DSI =). And it's
common to have multiple i2c or spi devices behind one bus. And all the
i2c and spi devices are actually connected to the host, which is not the
case with DSI.

> All the case that I know have only a single DSI device as well. I'm
> beginning to wonder why I even bother with all this.

I have similar thoughts. I haven't even seen new DSI devices used on the
platforms I work on for some time, I guess DSI is out of fashion. So
don't consider me arguing here as "nack", I just want to bring out the
issues and thoughts I've encountered with DSI.

>> So... While having a Linux DSI bus, etc. would feel elegant and nice, I
>> just feel it's not easy and not worth it.
> 
> Really the only reason why I've been pushing for this is because Laurent
> wanted me to represent DSI panels as children of a DSI bus in DT for the
> simple-panel bindings. The only solution to do this somewhat generically
> is to have a DSI bus binding and that sort of implies a DSI bus
> implementation.

I also think it's good to have DSI panels as children of the DSI host.
But that doesn't mean a bus implementation. You can as well have
platform devices as panels, and they may be children of the DSI host.
That's what I do on omap. That allows me to describe the HW correctly in
the DT data, but keep the linux driver side simple.

> The particular use-case that I care about works without any of this as
> well.
> 
>> 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.
> 
> So in fact you do consider DSI a control *and* data bus, but you're
> side-stepping the issue by hiding things within the drivers. But you
> still need to hook up the DSI device to an I2C master and a DSI host
> before you can use it. The reason why you can hide that is probably
> because it isn't generic and you couldn't reuse the peripheral DSI
> drivers on a different DSI host.

Hmm, no, I don't see anything omap specific in our implementation. Well,
ok, it's omap specific, but the DSI peripheral drivers just use generic
DSI ops which could as well be implemented on any other platform.

And I don't see it hiding anything. Can you be more specific?

If there was a simple way to have a single Linux device sitting on two
buses (DSI and I2C), I think it could make sense to have a Linux DSI bus
and Linux DSI device. But afaik it's not simple, and as we anyway have a
video "link" for DSI which can easily used for the control side, it much
simpler not to have the DSI bus at all. Especially as the DSI bus would
have just one device anyway.

>> 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.
> 
> I don't see how other devices would be broken. For one you can easily
> keep your existing code. We're adding new API here so there's no need at
> all to migrate to it and no way for it to break existing functionality.

Right. That's why I said in my original reply "(I speak here more in the
context of OMAP display subsystem and CDF, and
this might not be totally applicable to DRM).". I didn't mean current
drivers would be broken, I meant the new code should have theoretical
means to support the known existing hardware.

> But it will obviously be some work to move to a generic "framework", if
> you can call it that. The driver will likely need some major rewrite,
> which I think will be the case anyway because this will be a DRM API and
> you'll have to move to DRM to use it.

Yep. I think the most important part is to have somewhat sane DT data
with all the relevant information. It'd be nice to see an example of
that kind of data there would be used with this patch.

 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/d30d890f/attachment-0001.pgp>