RE: Requirement for DSI video mode support
Hi, Tomi Valkeinen wrote: Hi, On Mon, 2010-09-20 at 22:18 +0200, ext Jorge Bustamante wrote: Hi, We (TI) have been working on a DSI video mode driver for OMAP4 and I I hope it's also for OMAP3? am aware that other people are working with similar drivers. We had to tweak the code to make the drivers work with current code but we would like to make it the correct way, that is, introducing a proper functionality instead of inserting tweaks in the present command mode driver. Therefore, there is an initiative from us to modify current dss/dsi code to support DSI video mode. We have collected a list of requirements and ideas (with the help of ppl copied) from our experience working with these drivers, but it would be great if you can discuss/comment further on this. Requirements: - A better way of exposing VC's to a panel driver, since most panels use more than one VC. Currently the design supports only one per panel. Perhaps a VC resource pool could be created. Hmm, why would most panels use more than one VC? I haven't seen a single one =). Command mode panels will work fine with a single VC, I don't think video mode can run by using only one VC. Also, for command mode, there isn't a restriction to use a single VC. If you configure one VC to have slave port as source and the other as video port, the need to switch the VC source between L4 and VP would go away. The most optimal way would be to use one VC for each peripheral, but I don't think the usecase of connecting 4 panels to the same DSI lanes would ever be needed. Nevertheless, it should be possible to use multiple VCs in one driver. I've implemented a driver for a buffer chip that used all 4 channels. So did you connect more than one panel to DSI? I am curious about how it works [snip] - If we want a user to switch between modes, we may need to have a While I don't see any reason to forbid changing modes, I don't see any real reason to implement switching between the modes either. If it comes for free, sure, but if it means lots of implementation, I'd rather leave it out. Or do you have some use cases where switching modes is important? There isn't any use case where we would use a panel for video mode and command mode at different points in time. But if the panel supports both video and command mode there should be some option (compile time/ boot time) to choose which mode is to be used. I guess its more for the sake of completeness of the panels capabilities. Regards, Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Requirement for DSI video mode support
On Wed, 2010-10-27 at 08:34 +0200, ext Taneja, Archit wrote: Hi, Tomi Valkeinen wrote: Hi, On Mon, 2010-09-20 at 22:18 +0200, ext Jorge Bustamante wrote: Hi, We (TI) have been working on a DSI video mode driver for OMAP4 and I I hope it's also for OMAP3? am aware that other people are working with similar drivers. We had to tweak the code to make the drivers work with current code but we would like to make it the correct way, that is, introducing a proper functionality instead of inserting tweaks in the present command mode driver. Therefore, there is an initiative from us to modify current dss/dsi code to support DSI video mode. We have collected a list of requirements and ideas (with the help of ppl copied) from our experience working with these drivers, but it would be great if you can discuss/comment further on this. Requirements: - A better way of exposing VC's to a panel driver, since most panels use more than one VC. Currently the design supports only one per panel. Perhaps a VC resource pool could be created. Hmm, why would most panels use more than one VC? I haven't seen a single one =). Command mode panels will work fine with a single VC, I don't think video mode can run by using only one VC. Okay, I think we're talking about different VCs =). It's rather confusing in the TRM. A VC (in DSI packet sense) refers to the channel ID sent in the packet, and a VC (in OMAP DSS register sense) refers to a set of configurations used to send DSI packets. I think we need to come up with terms that clearly make the distinction between these, because they really don't have anything in common. (I'd like to hear the rationale for naming OMAP's config registers as VCs... =). Also, for command mode, there isn't a restriction to use a single VC. If you configure one VC to have slave port as source and the other as video port, the need to switch the VC source between L4 and VP would go away. This was what I had at some point. However, I was unsure how transmissions are synchronized in that case. If there's transmission going on from VP via, say, VC0, and I send a message from L4 via VC1, what happens? Does VC1 wait until VC0 is done? Or does it send the packet between VC0's packets? But I agree, different VCs for L4 and VP usage would make some things a bit simpler. The most optimal way would be to use one VC for each peripheral, but I don't think the usecase of connecting 4 panels to the same DSI lanes would ever be needed. Yes, that is quite unlikely. But it's difficult to say what kind of devices one needs to connect (see below), but it could be that we may come up with some kind of rules that fit to all cases. For example, is there ever need to have to OMAP VCs configured as VP at the same time? If not, we know that there will always be 3 OMAP VCs free for L4 use. Etc. (I didn't think this really, just throwing ideas =). Nevertheless, it should be possible to use multiple VCs in one driver. I've implemented a driver for a buffer chip that used all 4 channels. So did you connect more than one panel to DSI? I am curious about how it works The chip had it's own framebuffer memory, and you could connect two displays to the chip. The virtual channel mapping was something like this: 0 - routed to first panel 1 - routed to second panel 2 - buffer chip config 3 - buffer chip framebuffer config [snip] - If we want a user to switch between modes, we may need to have a While I don't see any reason to forbid changing modes, I don't see any real reason to implement switching between the modes either. If it comes for free, sure, but if it means lots of implementation, I'd rather leave it out. Or do you have some use cases where switching modes is important? There isn't any use case where we would use a panel for video mode and command mode at different points in time. But if the panel supports both video and command mode there should be some option (compile time/ boot time) to choose which mode is to be used. I guess its more for the sake of completeness of the panels capabilities. I agree. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Requirement for DSI video mode support
Hi, Command mode panels will work fine with a single VC, I don't think video mode can run by using only one VC. Okay, I think we're talking about different VCs =). It's rather confusing in the TRM. A VC (in DSI packet sense) refers to the channel ID sent in the packet, and a VC (in OMAP DSS register sense) refers to a set of configurations used to send DSI packets. I think we need to come up with terms that clearly make the distinction between these, because they really don't have anything in common. (I'd like to hear the rationale for naming OMAP's config registers as VCs... =). Yeah, it took me a while to figure out the difference from the TRM too. As far as the driver is concerned, I think there was a dest_per member for each set of VC configurations, that really made things clear. Its not in the present kernel, but it would be nice to get it back. The present approach always correlates VC0 configuration to VC_ID 0, 1 to 1 and so on. That confused me for a while again :| Also, for command mode, there isn't a restriction to use a single VC. If you configure one VC to have slave port as source and the other as video port, the need to switch the VC source between L4 and VP would go away. This was what I had at some point. However, I was unsure how transmissions are synchronized in that case. If there's transmission going on from VP via, say, VC0, and I send a message from L4 via VC1, what happens? Does VC1 wait until VC0 is done? Or does it send the packet between VC0's packets? I don't know how things works internally, but I am sure the 2 VC configuration works for a handful of phones :) Is this a thing that should be explained in the DSI specification, or is this something that should be taken care of while implementing DSI hardware? I'll try to find out. But I agree, different VCs for L4 and VP usage would make some things a bit simpler. The most optimal way would be to use one VC for each peripheral, but I don't think the usecase of connecting 4 panels to the same DSI lanes would ever be needed. Yes, that is quite unlikely. But it's difficult to say what kind of devices one needs to connect (see below), but it could be that we may come up with some kind of rules that fit to all cases. For example, is there ever need to have to OMAP VCs configured as VP at the same time? If not, we know that there will always be 3 OMAP VCs free for L4 use. Etc. (I didn't think this really, just throwing ideas =). Yes it would be good to more of such rules. I don't think the one above is valid for OMAP4 though. One of the DSI blocks has 2 video ports as input. One VC can be configured in Video mode + Video Port and the other can be Command mode + Video port, and command mode and video port can run together. We haven't tried it out yet (and don't want to either :)) Nevertheless, it should be possible to use multiple VCs in one driver. I've implemented a driver for a buffer chip that used all 4 channels. So did you connect more than one panel to DSI? I am curious about how it works The chip had it's own framebuffer memory, and you could connect two displays to the chip. The virtual channel mapping was something like this: 0 - routed to first panel 1 - routed to second panel 2 - buffer chip config 3 - buffer chip framebuffer config That's interesting, slightly out of topic question: How would a buffer chip / LVDS bridge chip fit in the DSS2 fw. Should it be in the panel driver or have its own driver? Asking out of curiosity. Regards, Archit-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Requirement for DSI video mode support
On Wed, 2010-10-27 at 10:17 +0200, ext Taneja, Archit wrote: Hi, Command mode panels will work fine with a single VC, I don't think video mode can run by using only one VC. Okay, I think we're talking about different VCs =). It's rather confusing in the TRM. A VC (in DSI packet sense) refers to the channel ID sent in the packet, and a VC (in OMAP DSS register sense) refers to a set of configurations used to send DSI packets. I think we need to come up with terms that clearly make the distinction between these, because they really don't have anything in common. (I'd like to hear the rationale for naming OMAP's config registers as VCs... =). Yeah, it took me a while to figure out the difference from the TRM too. As far as the driver is concerned, I think there was a dest_per member for each set of VC configurations, that really made things clear. There was, yes. But that wasn't perfect either. You can use one OMAP VC register set to send packets to any peripheral by using different virtual channel ID. Its not in the present kernel, but it would be nice to get it back. The present approach always correlates VC0 configuration to VC_ID 0, 1 to 1 and so on. That confused me for a while again :| Also, for command mode, there isn't a restriction to use a single VC. If you configure one VC to have slave port as source and the other as video port, the need to switch the VC source between L4 and VP would go away. This was what I had at some point. However, I was unsure how transmissions are synchronized in that case. If there's transmission going on from VP via, say, VC0, and I send a message from L4 via VC1, what happens? Does VC1 wait until VC0 is done? Or does it send the packet between VC0's packets? I don't know how things works internally, but I am sure the 2 VC configuration works for a handful of phones :) Is this a thing that should be explained in the DSI specification, or is this something that should be taken care of while implementing DSI hardware? I'll try to find out. It's DSI implementation spesific. It's about how OMAP HW handles the transmissions. I would guess that multiple OMAP VCs can send packets at the same time (but one packet on the DSI lines at one time, of course). But I'm not sure. But I agree, different VCs for L4 and VP usage would make some things a bit simpler. The most optimal way would be to use one VC for each peripheral, but I don't think the usecase of connecting 4 panels to the same DSI lanes would ever be needed. Yes, that is quite unlikely. But it's difficult to say what kind of devices one needs to connect (see below), but it could be that we may come up with some kind of rules that fit to all cases. For example, is there ever need to have to OMAP VCs configured as VP at the same time? If not, we know that there will always be 3 OMAP VCs free for L4 use. Etc. (I didn't think this really, just throwing ideas =). Yes it would be good to more of such rules. I don't think the one above is valid for OMAP4 though. One of the DSI blocks has 2 video ports as input. One VC can be configured in Video mode + Video Port and the other can be Command mode + Video port, and command mode and video port can run together. We haven't tried it out yet (and don't want to either :)) Nevertheless, it should be possible to use multiple VCs in one driver. I've implemented a driver for a buffer chip that used all 4 channels. So did you connect more than one panel to DSI? I am curious about how it works The chip had it's own framebuffer memory, and you could connect two displays to the chip. The virtual channel mapping was something like this: 0 - routed to first panel 1 - routed to second panel 2 - buffer chip config 3 - buffer chip framebuffer config That's interesting, slightly out of topic question: How would a buffer chip / LVDS bridge chip fit in the DSS2 fw. Should it be in the panel driver or have its own driver? Asking out of curiosity. In a perfect world we would have separate panel drivers for the panels, and driver for the buffer chip. And they could be connected as you want. But my implementation was a combined buffer chip/panel driver, handling everything. The DSS architecture isn't flexible enough (yet =). Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Requirement for DSI video mode support
Hi, Please see [YQ]. Regards, Youcef Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, October 27, 2010 2:18 PM To: Taneja, Archit Cc: ext Jorge Bustamante; linux-omap@vger.kernel.org; Iovescu, Magdalena; Menon, Nishanth; Qassid, Youcef; Aguirre, Alberto Subject: RE: Requirement for DSI video mode support On Wed, 2010-10-27 at 10:17 +0200, ext Taneja, Archit wrote: Hi, Command mode panels will work fine with a single VC, I don't think video mode can run by using only one VC. Okay, I think we're talking about different VCs =). It's rather confusing in the TRM. A VC (in DSI packet sense) refers to the channel ID sent in the packet, and a VC (in OMAP DSS register sense) refers to a set of configurations used to send DSI packets. I think we need to come up with terms that clearly make the distinction between these, because they really don't have anything in common. (I'd like to hear the rationale for naming OMAP's config registers as VCs... =). Yeah, it took me a while to figure out the difference from the TRM too. As far as the driver is concerned, I think there was a dest_per member for each set of VC configurations, that really made things clear. There was, yes. But that wasn't perfect either. You can use one OMAP VC register set to send packets to any peripheral by using different virtual channel ID. [YQ]: Command Mode will work fine with any OMAP VC register as you can control the VC ID field (generally set to 0). But you cannot control the VC for synchronization packets that are generated and sent automatically by the DSI is in Video Mode. Its not in the present kernel, but it would be nice to get it back. The present approach always correlates VC0 configuration to VC_ID 0, 1 to 1 and so on. That confused me for a while again :| Also, for command mode, there isn't a restriction to use a single VC. If you configure one VC to have slave port as source and the other as video port, the need to switch the VC source between L4 and VP would go away. This was what I had at some point. However, I was unsure how transmissions are synchronized in that case. If there's transmission going on from VP via, say, VC0, and I send a message from L4 via VC1, what happens? Does VC1 wait until VC0 is done? Or does it send the packet between VC0's packets? I don't know how things works internally, but I am sure the 2 VC configuration works for a handful of phones :) Is this a thing that should be explained in the DSI specification, or is this something that should be taken care of while implementing DSI hardware? I'll try to find out. It's DSI implementation spesific. It's about how OMAP HW handles the transmissions. I would guess that multiple OMAP VCs can send packets at the same time (but one packet on the DSI lines at one time, of course). But I'm not sure. [YQ] While using OCP (L3/L4) and Video Port interfaces for Command Mode you have several possibilities on OMAP4. You can choose the arbitration scheme. While the DSI is used in Video Mode, the packets you want to send via the OCP interface are transmitted during the blanking time. It is the interleaved mode. You have to respect some timing constraint for this feature. This is my understanding. I still have to validate these on silicon. But I agree, different VCs for L4 and VP usage would make some things a bit simpler. The most optimal way would be to use one VC for each peripheral, but I don't think the usecase of connecting 4 panels to the same DSI lanes would ever be needed. Yes, that is quite unlikely. But it's difficult to say what kind of devices one needs to connect (see below), but it could be that we may come up with some kind of rules that fit to all cases. For example, is there ever need to have to OMAP VCs configured as VP at the same time? If not, we know that there will always be 3 OMAP VCs free for L4 use. Etc. (I didn't think this really, just throwing ideas =). Yes it would be good to more of such rules. I don't think the one above is valid for OMAP4 though. One of the DSI blocks has 2 video ports as input. One VC can be configured in Video mode + Video Port and the other can be Command mode + Video port, and command mode and video port can run together. We haven't tried it out yet (and don't want to either :)) Nevertheless, it should be possible to use multiple VCs in one driver. I've implemented a driver for a buffer chip that used all 4 channels. So did you connect more than one panel to DSI? I am curious about how it works The chip had it's own framebuffer memory, and you could connect two displays to the chip. The virtual channel mapping was something like this: 0 - routed to first panel 1 - routed to second panel 2
Re: Requirement for DSI video mode support
On Fri, Oct 8, 2010 at 5:12 AM, Tomi Valkeinen tomi.valkei...@nokia.com wrote:
Hi,
On Mon, 2010-09-20 at 22:18 +0200, ext Jorge Bustamante wrote:
Hi,
We (TI) have been working on a DSI video mode driver for OMAP4 and I
I hope it's also for OMAP3?
I am not aware of any videomode display using OMAP3... so it would be
hard to test it with OMAP3, but I think we can make sure that it
doesn't break existing command mode drivers there at least.
am aware that other people are working with similar drivers. We had to
tweak the code to make the drivers work with current code but we would
like to make it the correct way, that is, introducing a proper
functionality instead of inserting tweaks in the present command mode
driver. Therefore, there is an initiative from us to modify current
dss/dsi code to support DSI video mode.
We have collected a list of requirements and ideas (with the help of
ppl copied) from our experience working with these drivers, but it
would be great if you can discuss/comment further on this.
Requirements:
- A better way of exposing VC's to a panel driver, since most panels
use more than one VC. Currently the design supports only one per
panel. Perhaps a VC resource pool could be created.
Hmm, why would most panels use more than one VC? I haven't seen a single
one =).
Nevertheless, it should be possible to use multiple VCs in one driver.
I've implemented a driver for a buffer chip that used all 4 channels.
But it's true that there's no allocation of the VCs, so if you have two
panels at the same time, there's no proper way to make sure they don't
use overlapping VCs.
You are right, my sentence was wrong regarding VCs, most of them -if
not all- require just one VC, but it is still handy as you mention to
be able to use more than one; for instance, using one for sending
commands (LP mode) and one for video data (HS mode), both pointing to
same VC ID of course. Since VCs are not tied to a particular VC ID, I
think we can manage them as mere resources and implementing some kind
of pool sounds good to me in order to avoid overlapping VCs as you
mention.
- A way of imposing restrictions on clock sources based on dsi mode.
- Runtime calculation of required clocks and PLL parameters. This is
to reduce complexity in clock calculations, specially when having two
panels running at the same time.
- A way to pass specific requirements from panel driver to DSI driver
(enable/disable BTA, set HS Clk always on, etc).
- Remove some hardcoded values in dsi.c and make the panel pass the
information to DSI driver(RX, TX fifo sizes of VCs, enabling/disabling
dsi timers, etc)
- A cleaner way of handling both DSI1 and DSI2 blocks(and more in
omap5) in the same driver.
- A way to easily set non-burst event mode, non-burst pulse mode and
burst mode configuration as defined on DSI protocol specs.
- A way to calculate correct DSI blanking parameters based on panel
blanking requirements (for DSI Video panels, these will be have to be
specified statically somewhere, much like DPI displays).
- Remove timeout error/warnings when disabling dsi phy interface since
on video mode it should wait instead for next vsync.
These are sound good to me.
Design ideas:
- It could actually be worthwhile to have separate files for command
and video mode and a core dsi driver file.
I think that's a good choice. At some point I thought of separating DSI
PLL, CIO and core stuff to separate files, but I never had time. And it
would also mean making lots of functions non-static.
From my personal point of view, we could probably manage to make it
work on same file and test it for a while first and just then try to
do it on separate files to avoid making a lot of changes at once. This
is having in mind that most of the proposed points are actually
additions that apply to DSI command mode as well (BTA, HS clocks, VCs,
etc).
- We can have a enum like this to choose between modes:
plat/display.h can have an enum like:
enum omap_dss_dsi_mode {
OMAP_DSS_DSI_CMDMODE = 1 0,
OMAP_DSS_DSI_VIDEOMODE = 1 1,
};
Nit pick - either make it #define and have bit offset as above OR
Better still, you wont need both at the same time, so bit offset wont be
useful too much.. OMAP_DSS_DSI_CMDMODE = 1, OMAP_DSS_DSI_VIDEOMODE = 2,
- If we want a user to switch between modes, we may need to have a
While I don't see any reason to forbid changing modes, I don't see any
real reason to implement switching between the modes either. If it comes
for free, sure, but if it means lots of implementation, I'd rather leave
it out. Or do you have some use cases where switching modes is
important?
Tomi
Again, you are right, I believe that dynamically switching modes is
not that important now, and agree that there is not a real reason to
implement it... probably it wouldn't be that hard to include it but I
think the simpler the patch the better for now, right?
Regards,
Jorge
Re: Requirement for DSI video mode support
Hi,
On Mon, 2010-09-20 at 22:18 +0200, ext Jorge Bustamante wrote:
Hi,
We (TI) have been working on a DSI video mode driver for OMAP4 and I
I hope it's also for OMAP3?
am aware that other people are working with similar drivers. We had to
tweak the code to make the drivers work with current code but we would
like to make it the correct way, that is, introducing a proper
functionality instead of inserting tweaks in the present command mode
driver. Therefore, there is an initiative from us to modify current
dss/dsi code to support DSI video mode.
We have collected a list of requirements and ideas (with the help of
ppl copied) from our experience working with these drivers, but it
would be great if you can discuss/comment further on this.
Requirements:
- A better way of exposing VC's to a panel driver, since most panels
use more than one VC. Currently the design supports only one per
panel. Perhaps a VC resource pool could be created.
Hmm, why would most panels use more than one VC? I haven't seen a single
one =).
Nevertheless, it should be possible to use multiple VCs in one driver.
I've implemented a driver for a buffer chip that used all 4 channels.
But it's true that there's no allocation of the VCs, so if you have two
panels at the same time, there's no proper way to make sure they don't
use overlapping VCs.
- A way of imposing restrictions on clock sources based on dsi mode.
- Runtime calculation of required clocks and PLL parameters. This is
to reduce complexity in clock calculations, specially when having two
panels running at the same time.
- A way to pass specific requirements from panel driver to DSI driver
(enable/disable BTA, set HS Clk always on, etc).
- Remove some hardcoded values in dsi.c and make the panel pass the
information to DSI driver(RX, TX fifo sizes of VCs, enabling/disabling
dsi timers, etc)
- A cleaner way of handling both DSI1 and DSI2 blocks(and more in
omap5) in the same driver.
- A way to easily set non-burst event mode, non-burst pulse mode and
burst mode configuration as defined on DSI protocol specs.
- A way to calculate correct DSI blanking parameters based on panel
blanking requirements (for DSI Video panels, these will be have to be
specified statically somewhere, much like DPI displays).
- Remove timeout error/warnings when disabling dsi phy interface since
on video mode it should wait instead for next vsync.
These are sound good to me.
Design ideas:
- It could actually be worthwhile to have separate files for command
and video mode and a core dsi driver file.
I think that's a good choice. At some point I thought of separating DSI
PLL, CIO and core stuff to separate files, but I never had time. And it
would also mean making lots of functions non-static.
- We can have a enum like this to choose between modes:
plat/display.h can have an enum like:
enum omap_dss_dsi_mode {
OMAP_DSS_DSI_CMDMODE = 1 0,
OMAP_DSS_DSI_VIDEOMODE = 1 1,
};
Nit pick - either make it #define and have bit offset as above OR
Better still, you wont need both at the same time, so bit offset wont be
useful too much.. OMAP_DSS_DSI_CMDMODE = 1, OMAP_DSS_DSI_VIDEOMODE = 2,
- If we want a user to switch between modes, we may need to have a
While I don't see any reason to forbid changing modes, I don't see any
real reason to implement switching between the modes either. If it comes
for free, sure, but if it means lots of implementation, I'd rather leave
it out. Or do you have some use cases where switching modes is
important?
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
