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

[Tomi Valkeinen]

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

Btw, about single linux device handling multiple VC IDs: I noticed that
the DSI spec has an example, in which a DSI peripheral receives
interlaced video, and the video packets containing even field have VC ID
0 and packets for odd field have VC ID 1. I'm not sure how relevant
interlaced video is, but I think there's an example where having
separate linux devices for each VC ID would be somewhat clumsy.

>> 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.
> 
> So it is the DSI hub driver that translates VC 0 to VC 2? How does it
> know that VC 0 should be VC 2 but not VC 3? Does the panel 2 driver pass
> in a different VC as panel 1?

I'm not sure what you mean. The routing information is passed via DT
data and then configured to the hub HW, or is hardcoded in the hub hardware.

> It's really the same thing. If you define VC IDs in a link local manner
> you don't need them at all. What's the point in having them if you can
> only reach a single device anyway.

You have to define the VC IDs somewhere in link-local manner for the HW
to work. The panels in my example respond to VC ID 0, even if from SW
(DSI host's) point of view they are addressed with VC ID 2 or 3. Both VC
ID 0 and VC IDs 2 and 3 need to be programmed to the hub and possibly to
the panel.

> From a software perspective we can always only describe devices from the
> viewpoint where things leave software control. In this case the last
> point of control is the DSI host. Therefore if we want to send a packet
> to any device connected to the DSI host (whether directly or through a
> hub), we need to pass some VC ID to the DSI host as a destination. That
> number needs to be known up front.
> 
> So either you hide that information in some software framework, such as
> you seem to be doing given your example above, and make the panel driver
> call into the hub driver and have the hub driver translate the VC ID to
> a different one.
> 
> The alternative would be to pass the correct address to the DSI host
> directly. Either way, though, whatever is written into the registers of
> the DSI host will end up the same, won't it?

Yes.

> You always address peripherals from the DSI host's viewpoint.

Yes. Except, of course, if the hub can be accessed with i2c also, in
which case you need some other addressing mechanism.

>> 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...
> 
> Why does that ruin it? You still address panel at 0 using VC 2 and panel at 1
> using VC 3, don't you? Therefore I see no reason why they shouldn't be
> represented as DSI devices with their respective VC IDs.

The DT data should reflect the hardware. In this case both panels are
addressed by the DSI hub with VC ID 0. That information has to be
somewhere, and logical place for it is to define the panels as having VC
ID 0.

The fact that the DSI host can send a packet to VC ID 3, and the hub
routes it to the second panel, is then part of the hub's operation.

>> But this DT example shows how DSI is really a one-to-one bus in the
>> hardware.
> 
> How is that one-to-one? The DSI hub connects to two peripherals, that's
> one-to-two.

Well, we keep going around this subject.

I'm speaking from the HW perspective. DSI link is a point to point link.
Each DSI link is totally independent, having its own speed and
configuration. The two output ports on the hub are as independent as two
DSI hosts on a SoC. Any routing that happens between DSI links is
totally up to the hub.

I agree that from SW perspective we can say the DSI hub connects to two
peripherals, addressed with VC2 and VC3. But we can't ignore the HW
side, as that information is required to program the hardware settings
properly (e.g. the routing configuration in the hub).

>> 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. If they had the same VC ID how do you address them differently? When
> the transactions originate at the DSI host, you have to tell it where
> they should go. If you pass them the same VC ID they will go to the same
> device. They have to.

I was speaking from HW perspective. Both panels respond to VC ID 0. The
hub manages the translation.

> What you say above could only be done if the hub actually had the
> possibility to initiate transactions of its own. But in that case it
> becomes a DSI host itself, rather than a simple hub.

Well, what is a "DSI host"? From HW perspective, the hub is a DSI host.
Or actually two DSI hosts, one for each panel. It buffers the packets it
receives from the SoC, which can come via DSI, i2c, or any other means,
and then sends them forward.

> Well, at least a hub would need to interpret the VC IDs. Take this
> example:
> 
> 	DSI host --> DSI hub --> peripheral 1 (VC ID 2)
> 	                     |
> 	                     --> peripheral 2 (VC ID 3)
> 
> If DSI host initiates a transaction addressed at VC 2, the DSI host will
> receive the packet, parse the VC and forward it to peripheral 1. In the
> same way, when the DSI hub receives a packet addressed at VC 3, it'll
> have to forward it to peripheral 2.
> 
> So a hub would probably need to have some mechanism to configure which
> downstream port corresponds to which VC ID. Upon initialization you need
> to program some registers to make the hub do the right thing.

Right, if there's routing happening, the VC ID needs to be parsed.

>> 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.
> 
> But you can have repeaters and such for I2C as well. Either way, I don't
> see how the physical connections are related to whether DSI should or
> should not be modeled as a Linux bus. PCI is modeled as a bus and can
> easily originate from a single root complex.

True.

So, how would a hub be modeled? We'd still need to model the real
hardware topology, right? That's what PCI does also, if I'm not mistaken.

Would we have one DSI bus for each DSI master on the SoC? And the hub
would be a device on that bus, and the panels would be children of that
hub device?

How are the logical VC ID (i.e. from SW perspective) and real VC ID (HW
perspective) present there?

Then, how does it work if we have an external DSI encoder, which uses
i2c for control and DPI for input video data, and outputs DSI to a
panel? Do we have a DSI bus somewhere? If we don't, how does the DSI
panel driver, connected to that DSI encoder, work?

I guess in that case the external encoder driver would register a DSI
bus. So generally speaking, an external encoder that outputs DSI would
register a DSI bus except if it is a DSI receiver itself, and it can
route DSI packets.

>> 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.
> 
> We don't have to represent it exactly matching the hardware. What we
> should be doing is represent it in a way that makes it convenient to
> use.

True, but here we need to know that a panel is connected to this hub's
that port, and the panel responds to VC ID x, and the hub routes VC ID y
to VC ID x. We need that information somewhere to configure the HW.

>> 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.
> 
> The original proposal isn't at all complex. It's actually fairly simple.
> The bulk of the code is boilerplate to allow devices and drivers to be
> registered. And we don't even need to consider all the tricky cases. I'd
> very much like to avoid that in fact and rather get something that we
> can put to use now.

Agreed. If it works for all people concerned, and gives us a generic DSI
support for simple cases, I think we can just forget about DSI hubs,
routing, VC IDs etc, and get it merged.

> From a quick look what omapdss seems to be doing is allocate and assign
> virtual channels dynamically at runtime. I suppose that's a good way to
> solve the issue. It might become an issue if you have devices that have
> a fixed mapping where you can't program the routing.

It's not really like that. It's actually rather confusing, partly due to
the HW. The virtual channels allocated there are actually "configuration
sets", they have nothing to do with the virtual channel ids sent over
the DSI bus. I've no idea why the HW people used such confusing naming.
That's why I usually use the term "VC ID" when I refer to the ID sent
over the DSI bus.

The panel drivers define the VC ID themselves, however they see fit.

>> 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,
> 
> But how do we have that? How is it represented? There is no generic
> framework that allows this. It's specifically what this patch series is
> all about. We need a way to instantiate a device and have it hooked up
> to a DSI host such that drivers can use the DSI host to send commands to
> the peripherals.
> 
> Perhaps you have that in omapdss, the rest of us don't have that. We can
> obviously duplicate what you've done to a large extent, but the goal was
> to come up with something generic. If generic means that it'll take
> endless amounts of discussions, I don't think I want generic for now.
> I'd rather focus on something that works for my use-cases and get back
> to generic later on.

As I said, I'm not nacking the patch. If it works for you, it's fine.

I just want to raise the issues I have encountered and though about. If
we ever want to support all kinds of DSI configurations, my opinion is
that this kind of bus approach is difficult, whereas a simpler model as
used by omapdss works. Both can be generic code.

Then again, I've not worked much with linux buses, so I may be missing
something and it's actually easy to support different DSI scenarios with
a linux bus.

>> it much simpler not to have the DSI bus at all. Especially as the DSI
>> bus would have just one device anyway.
> 
> You keep saying that, and at the same time you keep bringing forth
> arguments why it's important to support things such as DSI hubs. Can we
> settle on one way or another?

Well, I keep saying that because I've been thinking that in the case we
have a DSI hub, we would have multiple Linux DSI buses. One for SoC, and
more for the DSI hub. If so, each of the buses have just one device.

If we can have one logical DSI bus, then it's different.

And I haven't said it's important to support DSI hubs. I've said I have
not seen such in production, possibly because they are very difficult to
use well and not worth the trouble. I wouldn't be surprised if there
never will such a device supported in Linux kernel. (that's purely
subjective, of course, and no, I make no guarantees that tomorrow
somebody won't be asking for DSI hub support).

My opinion is that as long as the DT data is good enough, we could as
well forget the hubs and multiple devices on the Linux driver side, and
consider DSI as a point-to-point video data link. If the DT is fine, we
could later extend the drivers if there's need for hubs.

If it still makes sense to have a Linux DSI bus which only ever contains
one device, then there should be a Linux bus for it. In my experience,
it's easier without such a bus.

>>> 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.
> 
> Well the simplest case, which I think will probably cover about 99% of
> use-cases would look something like this:
> 
> 	/* DSI host */
> 	dsi at 54300000 {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		/* DSI peripheral */
> 		panel at 0 {
> 			reg = <0>;
> 		};
> 	};

Yes, I think this looks fine. What I have in omapdss's current DT work
tree is basically the same, except I use the V4L2 style video ports, so
that I can construct longer video pipelines. If longer pipelines are not
needed, the port information is not needed as it can be deduced from the
above data (if it's ever needed).

> Which in that case has a hard-coded VC 0 for the panel. Other more
> complex use-cases could look like this:
> 
> 	dsi at 54300000 {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		hub at 0 {
> 			panel at 2 {
> 				reg = <2>;
> 			};
> 
> 			panel at 3 {
> 				reg = <3>;
> 			};
> 		};
> 	};
> 
> Shouldn't that be able to cover pretty much any scenario in existence?

This I think needs more information, as the routing needs to be defined.
But I think we can ignore the hub side, no one is using those at the moment.

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