On Mon, Dec 09, 2013 at 01:34:06PM +0200, Tomi Valkeinen wrote:
> 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.
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.
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.
> >> 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?
> 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.
> 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.
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@2f {
};
panel1: panel@30 {
};
panel2: panel@31 {
};
};
dsi {
hub@0 {
control = <&dsihub>;
};
panel@2 {
control = <&panel1>;
};
panel@3 {
control = <&panel2>;
};
};
> >> 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).
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.
> > 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?
> 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.
> 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.
> 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.
> 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.
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.
> 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.
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.
> 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.
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.
Thierry
Attachment:
pgpqf3YEtCOAh.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
