Hi Tomi, finally we have managed to get the ssd2858 rotator chip + panel running - except one issue.
We see some tearing because the SSD / panel runs at a slightly different VSYNC rate than the OMAP5.
We now have enabled a TE impulse from the ssd2858 chip going to dsiporta_te0 / gpio6_189.
The question is how to enable it on the OMAP5 side.
BR and thanks, Nikolaus
On 08/06/15 10:55, Dr. H. Nikolaus Schaller wrote:
Hi Tomi, finally we have managed to get the ssd2858 rotator chip + panel running - except one issue.
We see some tearing because the SSD / panel runs at a slightly different VSYNC rate than the OMAP5.
We now have enabled a TE impulse from the ssd2858 chip going to dsiporta_te0 / gpio6_189.
The question is how to enable it on the OMAP5 side.
I presume you are using the SSD2858 with DSI video mode input. There's no TE in that case. TE is only for DSI command mode.
Tomi
Hi,
Am 08.06.2015 um 10:10 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 08/06/15 10:55, Dr. H. Nikolaus Schaller wrote:
Hi Tomi, finally we have managed to get the ssd2858 rotator chip + panel running - except one issue.
We see some tearing because the SSD / panel runs at a slightly different VSYNC rate than the OMAP5.
We now have enabled a TE impulse from the ssd2858 chip going to dsiporta_te0 / gpio6_189.
The question is how to enable it on the OMAP5 side.
I presume you are using the SSD2858 with DSI video mode input.
Yes.
There's no TE in that case. TE is only for DSI command mode.
Oops. Hm. How can we then sync the panel (SSD2858 video out) with the OMAP5 DSI sync speed? Sort of “make DISPC wait for external VSYNC impulse”?
BR, Nikolaus
On 08/06/15 11:27, Dr. H. Nikolaus Schaller wrote:
Oops. Hm. How can we then sync the panel (SSD2858 video out) with the OMAP5 DSI sync speed? Sort of “make DISPC wait for external VSYNC impulse”?
You can't do it that way.
There's probably two options, depending on SSD2858 functionality:
1. Configure SSD2858 to use the input video timings. Thus SSD2858's output timings depend wholly on the input, and they are fully synchronized. SSD2858's timing generator is disabled.
2. Configure SSD2858 input and output video timings to be exactly the same, or very very nearly the same. Usually display chips have line buffers, and they allow slight skew on the input and output timings.
Tomi
Am Mon, 8 Jun 2015 11:10:39 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
We now have enabled a TE impulse from the ssd2858 chip going to dsiporta_te0 / gpio6_189. The question is how to enable it on the OMAP5 side.
I presume you are using the SSD2858 with DSI video mode input. There's no TE in that case. TE is only for DSI command mode.
I browsed the net quite a bit, trying to find out the differences between video mode, command mode and TE.
If I understand it correctly, TE mode is always only available in command mode (on any SoC, not just on the OMAP). So TE is officially for anti-tearing and only works in command mode - therefore, I wanted to find out what the differences are between video mode and command mode.
I found that site, which does explain it quite good: http://www.electronicproducts.com/Analog_Mixed_Signal_ICs/Communications_Int...
If I understand correctly, video mode is basically the same as the classic way (sending RGB signals). There's always a video stream being sent, usually without an external framebuffer, so unless you use the timings from the video stream, it's not possible to sychronize them (that's why TE doesn't work here).
Command mode has a different approach: It sends the frames as DCS packages to the LCD (or SSD in our case). The SSD/LCD needs to have a framebuffer to store it, displays it autonomously and then sends a TE signal back to the OMAP5 to tell it that the next package can be sent. Additionally, command mode supports stuff like only updating video data when necessary (i.e. if a smartphone shows a website without animation and the user doesn't scroll around, it doesn't to send frame packages and saves power).
First question: Did I understand that correctly, or is there something wrong?
Second question: Can we use the command mode on the OMAP5? Is this implemented in the driver? Does the driver (and the hardware) take care of everything or would we need to fix every program on Linux to make it work with the command mode?
Thanks in advance :)
Hi,
Am 10.06.2015 um 17:58 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 8 Jun 2015 11:10:39 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
We now have enabled a TE impulse from the ssd2858 chip going to dsiporta_te0 / gpio6_189. The question is how to enable it on the OMAP5 side.
I presume you are using the SSD2858 with DSI video mode input. There's no TE in that case. TE is only for DSI command mode.
I browsed the net quite a bit, trying to find out the differences between video mode, command mode and TE.
If I understand it correctly, TE mode is always only available in command mode (on any SoC, not just on the OMAP). So TE is officially for anti-tearing and only works in command mode - therefore, I wanted to find out what the differences are between video mode and command mode.
I found that site, which does explain it quite good: http://www.electronicproducts.com/Analog_Mixed_Signal_ICs/Communications_Int...
If I understand correctly, video mode is basically the same as the classic way (sending RGB signals). There's always a video stream being sent, usually without an external framebuffer, so unless you use the timings from the video stream, it's not possible to sychronize them (that's why TE doesn't work here).
Command mode has a different approach: It sends the frames as DCS packages to the LCD (or SSD in our case). The SSD/LCD needs to have a framebuffer to store it, displays it autonomously and then sends a TE signal back to the OMAP5 to tell it that the next package can be sent.
The SSD definitively has a frame buffer (where it reads the rotated image from) so it should be capable of command mode. Especially since it supports the TE output (and some DCS commands to program the scan line where TE impulses start).
Additionally, command mode supports stuff like only updating video data when necessary (i.e. if a smartphone shows a website without animation and the user doesn't scroll around, it doesn't to send frame packages and saves power).
First question: Did I understand that correctly, or is there something wrong?
From my (also not complete) experience and knowledge: yes
Second question: Can we use the command mode on the OMAP5? Is this implemented in the driver? Does the driver (and the hardware) take care of everything or would we need to fix every program on Linux to make it work with the command mode?
That is the key question. Or to reformulate / add questions:
* can command mode be used together with omapfb i.e. /dev/fb? * how fast is command mode compared to video mode? Same speed or slower?
BR, NIkolaus
Hi all, I have studied the OMAP5 TRM and section
10.2.4.12.6 DISPC Timing Generator and Panel Settings
describes that the DISPC indeed has a fixed format and I have not found a hint to trigger it by an external VSYNC. I wonder why TI didn’t add this to an already very complex SoC. We would not need all these tilers, replication filters, and pipelines, YUV transforms, etc. but such a simple feature to stretch the back porch until an external trigger arrives is missing…
BTW: the HDMI subsystem seems to have such a feature: „DISPC_TV_FID“ (Figure 10-83. DISPC TV Output Architecture).
But what about adding a (software) control loop around it?
The idea would be to act on two interrupts: a) the VSYNC1_IRQ interrupt from DISPC b) the TE input (as GPIO interrupt)
Both come with approx. 60Hz, i.e. very slowly. So the proposed mechanism isn’t heavy CPU load (could even be done by some Cortex M4 code if we ever manage to get it working).
Now my idea is that the CPU tries to measure the time between the interrupts.
Depending on the outcome we could try to increase or decrease VBP so that the control loop synchronises the DISPC speed *and* phase to the SSD TE output.
Could that work?
It would need: 1. detection of these interrupts 2. measuring/estimating the time between (can Linux do that? Is there a µs time stamp easily available?) 3. modify VBP setting of DISPC on the fly (i.e. without disturbing DISPC operation) - register DISPC_TIMING_Vo[31:20] - so that the difference is likely ~0 next time [1][2]
The question will become how that fits into the OMAP DSS driver architecture. Would it become a special mode or a separate „external sync“ driver module? Or should we try to integrate such a function into the ssd2858 panel driver (if possible)?
BR, Nikolaus
[1] if that scheme works, two such measurements and an arbitrary initial modification of VBP could allow to calculate the correct VBP value. So I think locking could be done in 2-3 frames. [2] it is not necessary to have 0 skew. It must just be small enough so that DISPC buffer swapping occurs during vertical blanking as indicated by the SSD. So I would assume that we have 20-30 lines error bandwidth. So interrupt context switch latency in the kernel is also not critical.
Am 10.06.2015 um 17:58 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 8 Jun 2015 11:10:39 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
We now have enabled a TE impulse from the ssd2858 chip going to dsiporta_te0 / gpio6_189. The question is how to enable it on the OMAP5 side.
I presume you are using the SSD2858 with DSI video mode input. There's no TE in that case. TE is only for DSI command mode.
I browsed the net quite a bit, trying to find out the differences between video mode, command mode and TE.
If I understand it correctly, TE mode is always only available in command mode (on any SoC, not just on the OMAP). So TE is officially for anti-tearing and only works in command mode - therefore, I wanted to find out what the differences are between video mode and command mode.
I found that site, which does explain it quite good: http://www.electronicproducts.com/Analog_Mixed_Signal_ICs/Communications_Int...
If I understand correctly, video mode is basically the same as the classic way (sending RGB signals). There's always a video stream being sent, usually without an external framebuffer, so unless you use the timings from the video stream, it's not possible to sychronize them (that's why TE doesn't work here).
Command mode has a different approach: It sends the frames as DCS packages to the LCD (or SSD in our case). The SSD/LCD needs to have a framebuffer to store it, displays it autonomously and then sends a TE signal back to the OMAP5 to tell it that the next package can be sent. Additionally, command mode supports stuff like only updating video data when necessary (i.e. if a smartphone shows a website without animation and the user doesn't scroll around, it doesn't to send frame packages and saves power).
First question: Did I understand that correctly, or is there something wrong?
Second question: Can we use the command mode on the OMAP5? Is this implemented in the driver? Does the driver (and the hardware) take care of everything or would we need to fix every program on Linux to make it work with the command mode?
Thanks in advance :)
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
Hi,
On Wed, Jun 10, 2015 at 11:06 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have studied the OMAP5 TRM and section
10.2.4.12.6 DISPC Timing Generator and Panel Settings
describes that the DISPC indeed has a fixed format and I have not found a hint to trigger it by an external VSYNC. I wonder why TI didn’t add this to an already very complex SoC. We would not need all these tilers, replication filters, and pipelines, YUV transforms, etc. but such a simple feature to stretch the back porch until an external trigger arrives is missing…
Agreed...
BTW: the HDMI subsystem seems to have such a feature: „DISPC_TV_FID“ (Figure 10-83. DISPC TV Output Architecture).
But what about adding a (software) control loop around it?
The idea would be to act on two interrupts: a) the VSYNC1_IRQ interrupt from DISPC b) the TE input (as GPIO interrupt)
Both come with approx. 60Hz, i.e. very slowly. So the proposed mechanism isn’t heavy CPU load (could even be done by some Cortex M4 code if we ever manage to get it working).
Now my idea is that the CPU tries to measure the time between the interrupts.
Depending on the outcome we could try to increase or decrease VBP so that the control loop synchronises the DISPC speed *and* phase to the SSD TE output.
Could that work?
It would need:
- detection of these interrupts
Should work.
- measuring/estimating the time between (can Linux do that? Is there a µs time stamp easily available?)
Sort of... You can read the µs timestamp fine but there will be random interrupt latency because the CPUs may be busy with other things (wakeup latency depending if CPU was asleep, higher priority interrupt handling or critical sections with irqs disabled) when our interrupts arrive - Linux is not a realtime OS. That said we already use similar hack to read pandora's touchscreen during vblank to avoid horrible noise we get doing that during active display and it works kind of ok.
- modify VBP setting of DISPC on the fly (i.e. without disturbing DISPC operation) - register DISPC_TIMING_Vo[31:20] - so that the difference is likely ~0 next time [1][2]
Note that DISPC_TIMING_Vx is a shadow register (hardware only reads it on VFP start), which may cause trouble, but hopefully it would work. Some filter code could be added to deal with latency spikes.
The question will become how that fits into the OMAP DSS driver architecture. Would it become a special mode or a separate „external sync“ driver module? Or should we try to integrate such a function into the ssd2858 panel driver (if possible)?
Sounds like it will be quite horrible with little chance of getting mainlined, so will be a maintenance burden forever either for us or whoever accepts it into mainline. Although it's probably better that out-of-tree pandora's TS hack where I had to fight against linux's driver isolation to get completely unrelated drivers to cooperate.
Anyway this sounds like the least bad solution so far, the other one being potential use of command mode with TE. Tomi, can command mode be used to achieve steady 60fps?
BR, Nikolaus
[1] if that scheme works, two such measurements and an arbitrary initial modification of VBP could allow to calculate the correct VBP value. So I think locking could be done in 2-3 frames.
I think it would need constant adjustment because of OMAP's and SSD's clocks being derived from separate crystals, and the smallest adjustment granularity we has is the whole line or column. The clock frequency difference will slightly differ between different units too, will be affected by temperatures and so on...
[2] it is not necessary to have 0 skew. It must just be small enough so that DISPC buffer swapping occurs during vertical blanking as indicated by the SSD. So I would assume that we have 20-30 lines error bandwidth. So interrupt context switch latency in the kernel is also not critical.
We can manipulate this somewhat by choosing large blanking periods, but still drifting needs to be dealt with somehow...
Am 10.06.2015 um 17:58 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 8 Jun 2015 11:10:39 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
We now have enabled a TE impulse from the ssd2858 chip going to dsiporta_te0 / gpio6_189. The question is how to enable it on the OMAP5 side.
I presume you are using the SSD2858 with DSI video mode input. There's no TE in that case. TE is only for DSI command mode.
I browsed the net quite a bit, trying to find out the differences between video mode, command mode and TE.
If I understand it correctly, TE mode is always only available in command mode (on any SoC, not just on the OMAP). So TE is officially for anti-tearing and only works in command mode - therefore, I wanted to find out what the differences are between video mode and command mode.
I found that site, which does explain it quite good: http://www.electronicproducts.com/Analog_Mixed_Signal_ICs/Communications_Int...
If I understand correctly, video mode is basically the same as the classic way (sending RGB signals). There's always a video stream being sent, usually without an external framebuffer, so unless you use the timings from the video stream, it's not possible to sychronize them (that's why TE doesn't work here).
Command mode has a different approach: It sends the frames as DCS packages to the LCD (or SSD in our case). The SSD/LCD needs to have a framebuffer to store it, displays it autonomously and then sends a TE signal back to the OMAP5 to tell it that the next package can be sent. Additionally, command mode supports stuff like only updating video data when necessary (i.e. if a smartphone shows a website without animation and the user doesn't scroll around, it doesn't to send frame packages and saves power).
First question: Did I understand that correctly, or is there something wrong?
Second question: Can we use the command mode on the OMAP5? Is this implemented in the driver? Does the driver (and the hardware) take care of everything or would we need to fix every program on Linux to make it work with the command mode?
Thanks in advance :)
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 10.06.2015 um 23:09 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
On Wed, Jun 10, 2015 at 11:06 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have studied the OMAP5 TRM and section
10.2.4.12.6 DISPC Timing Generator and Panel Settings
describes that the DISPC indeed has a fixed format and I have not found a hint to trigger it by an external VSYNC. I wonder why TI didn’t add this to an already very complex SoC. We would not need all these tilers, replication filters, and pipelines, YUV transforms, etc. but such a simple feature to stretch the back porch until an external trigger arrives is missing…
Agreed...
BTW: the HDMI subsystem seems to have such a feature: „DISPC_TV_FID“ (Figure 10-83. DISPC TV Output Architecture).
But what about adding a (software) control loop around it?
The idea would be to act on two interrupts: a) the VSYNC1_IRQ interrupt from DISPC b) the TE input (as GPIO interrupt)
Both come with approx. 60Hz, i.e. very slowly. So the proposed mechanism isn’t heavy CPU load (could even be done by some Cortex M4 code if we ever manage to get it working).
Now my idea is that the CPU tries to measure the time between the interrupts.
Depending on the outcome we could try to increase or decrease VBP so that the control loop synchronises the DISPC speed *and* phase to the SSD TE output.
Could that work?
It would need:
- detection of these interrupts
Should work.
- measuring/estimating the time between (can Linux do that? Is there a µs time stamp easily available?)
Sort of... You can read the µs timestamp fine but there will be random interrupt latency because the CPUs may be busy with other things (wakeup latency depending if CPU was asleep, higher priority interrupt handling or critical sections with irqs disabled) when our interrupts arrive - Linux is not a realtime OS.
Agreed. But I think the required precision is in the range of 10 scan lines, i.e. 130µs.
That said we already use similar hack to read pandora's touchscreen during vblank to avoid horrible noise we get doing that during active display and it works kind of ok.
- modify VBP setting of DISPC on the fly (i.e. without disturbing DISPC operation) - register DISPC_TIMING_Vo[31:20] - so that the difference is likely ~0 next time [1][2]
Note that DISPC_TIMING_Vx is a shadow register (hardware only reads it on VFP start), which may cause trouble, but hopefully it would work. Some filter code could be added to deal with latency spikes.
The question will become how that fits into the OMAP DSS driver architecture. Would it become a special mode or a separate „external sync“ driver module? Or should we try to integrate such a function into the ssd2858 panel driver (if possible)?
Sounds like it will be quite horrible with little chance of getting mainlined, so will be a maintenance burden forever either for us or whoever accepts it into mainline. Although it's probably better that out-of-tree pandora's TS hack where I had to fight against linux's driver isolation to get completely unrelated drivers to cooperate.
Anyway this sounds like the least bad solution so far,
:)
the other one being potential use of command mode with TE. Tomi, can command mode be used to achieve steady 60fps?
This would be better of course.
BR, Nikolaus
[1] if that scheme works, two such measurements and an arbitrary initial modification of VBP could allow to calculate the correct VBP value. So I think locking could be done in 2-3 frames.
I think it would need constant adjustment because of OMAP's and SSD's clocks being derived from separate crystals, and the smallest adjustment granularity we has is the whole line or column. The clock frequency difference will slightly differ between different units too, will be affected by temperatures and so on...
[2] it is not necessary to have 0 skew. It must just be small enough so that DISPC buffer swapping occurs during vertical blanking as indicated by the SSD. So I would assume that we have 20-30 lines error bandwidth. So interrupt context switch latency in the kernel is also not critical.
We can manipulate this somewhat by choosing large blanking periods, but still drifting needs to be dealt with somehow…
Drifting is accounted for by making it phase locked (and not frequency locked). I.e. if the frequencies disagree by let’s say 0.1 Hz, this might mean 20 lines skew per second. Enough time to regulate the VBP of the intermediate frames.
So I see no problem if the VBP is adjusted every now and then to keep the average frequency the same - and the sync pulses start roughly at the same moment.
Am 10.06.2015 um 17:58 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 8 Jun 2015 11:10:39 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
We now have enabled a TE impulse from the ssd2858 chip going to dsiporta_te0 / gpio6_189. The question is how to enable it on the OMAP5 side.
I presume you are using the SSD2858 with DSI video mode input. There's no TE in that case. TE is only for DSI command mode.
I browsed the net quite a bit, trying to find out the differences between video mode, command mode and TE.
If I understand it correctly, TE mode is always only available in command mode (on any SoC, not just on the OMAP). So TE is officially for anti-tearing and only works in command mode - therefore, I wanted to find out what the differences are between video mode and command mode.
I found that site, which does explain it quite good: http://www.electronicproducts.com/Analog_Mixed_Signal_ICs/Communications_Int...
If I understand correctly, video mode is basically the same as the classic way (sending RGB signals). There's always a video stream being sent, usually without an external framebuffer, so unless you use the timings from the video stream, it's not possible to sychronize them (that's why TE doesn't work here).
Command mode has a different approach: It sends the frames as DCS packages to the LCD (or SSD in our case). The SSD/LCD needs to have a framebuffer to store it, displays it autonomously and then sends a TE signal back to the OMAP5 to tell it that the next package can be sent. Additionally, command mode supports stuff like only updating video data when necessary (i.e. if a smartphone shows a website without animation and the user doesn't scroll around, it doesn't to send frame packages and saves power).
First question: Did I understand that correctly, or is there something wrong?
Second question: Can we use the command mode on the OMAP5? Is this implemented in the driver? Does the driver (and the hardware) take care of everything or would we need to fix every program on Linux to make it work with the command mode?
Thanks in advance :)
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
A few quick notes:
DISPC_TV_FID is something else.
Having that kind of "stretch back porch" would not comply with DSI standard. And, to me, sounds like quite a hack.
SSD data sheet says it supports video mode and command mode, and it says it support rotation. What you are discussing here is not related to rotation, but "how can video mode be used with SSD". The SSD docs should explain how video mode can be used (i.e. how the SSD input and output are syncronized).
If a device (SSD) supports video mode, it should be able to synchronize with the video input stream. I don't see how SSD could advertize supporting video mode if it cannot sync with the input.
Command mode should work with omapdss. omapfb has ioctl to send a frame. omapdrm doesn't support command mode. The command mode SW implementation is designed so that the expectation is that the userspace explicitly requests a frame to be updated, i.e. there's no "automatic update" support.
Also note that rotation requires double buffering in SSD, i.e. they have 2 x frame memory, update from SoC goes to one, while the other one is being displayed on panel. Presumably it requires config to use double buffering. If you don't do that, and update the same piece of memory from SoC while it's being displayed, you'll see diagonal tearing.
And if SSD doesn't have double buffering support, I don't see how they can support rotation (properly).
Tomi
On 06/11/2015 12:17 AM, Dr. H. Nikolaus Schaller wrote:
Am 10.06.2015 um 23:09 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
On Wed, Jun 10, 2015 at 11:06 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have studied the OMAP5 TRM and section
10.2.4.12.6 DISPC Timing Generator and Panel Settings
describes that the DISPC indeed has a fixed format and I have not found a hint to trigger it by an external VSYNC. I wonder why TI didn’t add this to an already very complex SoC. We would not need all these tilers, replication filters, and pipelines, YUV transforms, etc. but such a simple feature to stretch the back porch until an external trigger arrives is missing…
Agreed...
BTW: the HDMI subsystem seems to have such a feature: „DISPC_TV_FID“ (Figure 10-83. DISPC TV Output Architecture).
But what about adding a (software) control loop around it?
The idea would be to act on two interrupts: a) the VSYNC1_IRQ interrupt from DISPC b) the TE input (as GPIO interrupt)
Both come with approx. 60Hz, i.e. very slowly. So the proposed mechanism isn’t heavy CPU load (could even be done by some Cortex M4 code if we ever manage to get it working).
Now my idea is that the CPU tries to measure the time between the interrupts.
Depending on the outcome we could try to increase or decrease VBP so that the control loop synchronises the DISPC speed *and* phase to the SSD TE output.
Could that work?
It would need:
- detection of these interrupts
Should work.
- measuring/estimating the time between (can Linux do that? Is there a µs time stamp easily available?)
Sort of... You can read the µs timestamp fine but there will be random interrupt latency because the CPUs may be busy with other things (wakeup latency depending if CPU was asleep, higher priority interrupt handling or critical sections with irqs disabled) when our interrupts arrive - Linux is not a realtime OS.
Agreed. But I think the required precision is in the range of 10 scan lines, i.e. 130µs.
That said we already use similar hack to read pandora's touchscreen during vblank to avoid horrible noise we get doing that during active display and it works kind of ok.
- modify VBP setting of DISPC on the fly (i.e. without disturbing DISPC operation) - register DISPC_TIMING_Vo[31:20] - so that the difference is likely ~0 next time [1][2]
Note that DISPC_TIMING_Vx is a shadow register (hardware only reads it on VFP start), which may cause trouble, but hopefully it would work. Some filter code could be added to deal with latency spikes.
The question will become how that fits into the OMAP DSS driver architecture. Would it become a special mode or a separate „external sync“ driver module? Or should we try to integrate such a function into the ssd2858 panel driver (if possible)?
Sounds like it will be quite horrible with little chance of getting mainlined, so will be a maintenance burden forever either for us or whoever accepts it into mainline. Although it's probably better that out-of-tree pandora's TS hack where I had to fight against linux's driver isolation to get completely unrelated drivers to cooperate.
Anyway this sounds like the least bad solution so far,
:)
the other one being potential use of command mode with TE. Tomi, can command mode be used to achieve steady 60fps?
This would be better of course.
BR, Nikolaus
[1] if that scheme works, two such measurements and an arbitrary initial modification of VBP could allow to calculate the correct VBP value. So I think locking could be done in 2-3 frames.
I think it would need constant adjustment because of OMAP's and SSD's clocks being derived from separate crystals, and the smallest adjustment granularity we has is the whole line or column. The clock frequency difference will slightly differ between different units too, will be affected by temperatures and so on...
[2] it is not necessary to have 0 skew. It must just be small enough so that DISPC buffer swapping occurs during vertical blanking as indicated by the SSD. So I would assume that we have 20-30 lines error bandwidth. So interrupt context switch latency in the kernel is also not critical.
We can manipulate this somewhat by choosing large blanking periods, but still drifting needs to be dealt with somehow…
Drifting is accounted for by making it phase locked (and not frequency locked). I.e. if the frequencies disagree by let’s say 0.1 Hz, this might mean 20 lines skew per second. Enough time to regulate the VBP of the intermediate frames.
So I see no problem if the VBP is adjusted every now and then to keep the average frequency the same - and the sync pulses start roughly at the same moment.
Am 10.06.2015 um 17:58 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 8 Jun 2015 11:10:39 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
We now have enabled a TE impulse from the ssd2858 chip going to dsiporta_te0 / gpio6_189. The question is how to enable it on the OMAP5 side.
I presume you are using the SSD2858 with DSI video mode input. There's no TE in that case. TE is only for DSI command mode.
I browsed the net quite a bit, trying to find out the differences between video mode, command mode and TE.
If I understand it correctly, TE mode is always only available in command mode (on any SoC, not just on the OMAP). So TE is officially for anti-tearing and only works in command mode - therefore, I wanted to find out what the differences are between video mode and command mode.
I found that site, which does explain it quite good: http://www.electronicproducts.com/Analog_Mixed_Signal_ICs/Communications_Int...
If I understand correctly, video mode is basically the same as the classic way (sending RGB signals). There's always a video stream being sent, usually without an external framebuffer, so unless you use the timings from the video stream, it's not possible to sychronize them (that's why TE doesn't work here).
Command mode has a different approach: It sends the frames as DCS packages to the LCD (or SSD in our case). The SSD/LCD needs to have a framebuffer to store it, displays it autonomously and then sends a TE signal back to the OMAP5 to tell it that the next package can be sent. Additionally, command mode supports stuff like only updating video data when necessary (i.e. if a smartphone shows a website without animation and the user doesn't scroll around, it doesn't to send frame packages and saves power).
First question: Did I understand that correctly, or is there something wrong?
Second question: Can we use the command mode on the OMAP5? Is this implemented in the driver? Does the driver (and the hardware) take care of everything or would we need to fix every program on Linux to make it work with the command mode?
Thanks in advance :)
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
Am 11.06.2015 um 12:43 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
A few quick notes:
DISPC_TV_FID is something else.
I think I mixed it up with DISPC_TV_VSYNC coming from the HDMI timing generator.
Having that kind of "stretch back porch" would not comply with DSI standard. And, to me, sounds like quite a hack.
Sometimes a working quick hack is more valuable than a good and broad solution that is not available :)
SSD data sheet says it supports video mode and command mode, and it says it support rotation. What you are discussing here is not related to rotation, but “how can video mode be used with SSD".
There is some relation to rotation because rotation means that the HSYNC frequency on the input is different from the HSYNC frequency to the panel. Even if VSYNC is identical. But you are right - keeping input and output in VSYNC is also a problem in non-rotated mode.
The SSD docs should explain how video mode can be used (i.e. how the SSD input and output are syncronized).
They say (and we can confirm) that the SSD generates a TE output signal (even in video mode) and the video source must be synchronized to it…
If a device (SSD) supports video mode, it should be able to synchronize with the video input stream. I don’t see how SSD could advertize supporting video mode if it cannot sync with the input.
That would be a “stretch back porch” applied to the SSD output going to the panel.
I think we can pass-through both HSYNC and VSYNC but AFAIK this does not work in combination with rotation (because different HSYNC frequency requirements).
Command mode should work with omapdss. omapfb has ioctl to send a frame. omapdrm doesn't support command mode. The command mode SW implementation is designed so that the expectation is that the userspace explicitly requests a frame to be updated, i.e. there’s no "automatic update" support.
Understood. It looks to me as it makes using it with X11 or Qt a little difficult because AFAIK they expect a simply framebuffer and an auto-updating panel.
Also note that rotation requires double buffering in SSD, i.e. they have 2 x frame memory, update from SoC goes to one, while the other one is being displayed on panel. Presumably it requires config to use double buffering. If you don’t do that, and update the same piece of memory from SoC while it's being displayed, you'll see diagonal tearing.
I think we have enabled that and we see vertical tearing (i.e. the moment where buffers are swapped is not in sync).
And if SSD doesn't have double buffering support, I don't see how they can support rotation (properly).
Tomi
So it might end up that we have to try the second worst solution to sync the VSYNC interrupts by a daemon.
Or could the daemon simply to the same as the command mode ioctl()? I.e. we would trigger it by the panel VSYNC interrupt?
BR, Nikolaus
On 06/11/2015 12:17 AM, Dr. H. Nikolaus Schaller wrote:
Am 10.06.2015 um 23:09 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
On Wed, Jun 10, 2015 at 11:06 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have studied the OMAP5 TRM and section
10.2.4.12.6 DISPC Timing Generator and Panel Settings
describes that the DISPC indeed has a fixed format and I have not found a hint to trigger it by an external VSYNC. I wonder why TI didn’t add this to an already very complex SoC. We would not need all these tilers, replication filters, and pipelines, YUV transforms, etc. but such a simple feature to stretch the back porch until an external trigger arrives is missing…
Agreed...
BTW: the HDMI subsystem seems to have such a feature: „DISPC_TV_FID“ (Figure 10-83. DISPC TV Output Architecture).
But what about adding a (software) control loop around it?
The idea would be to act on two interrupts: a) the VSYNC1_IRQ interrupt from DISPC b) the TE input (as GPIO interrupt)
Both come with approx. 60Hz, i.e. very slowly. So the proposed mechanism isn’t heavy CPU load (could even be done by some Cortex M4 code if we ever manage to get it working).
Now my idea is that the CPU tries to measure the time between the interrupts.
Depending on the outcome we could try to increase or decrease VBP so that the control loop synchronises the DISPC speed *and* phase to the SSD TE output.
Could that work?
It would need:
- detection of these interrupts
Should work.
- measuring/estimating the time between (can Linux do that? Is there a µs time stamp easily available?)
Sort of... You can read the µs timestamp fine but there will be random interrupt latency because the CPUs may be busy with other things (wakeup latency depending if CPU was asleep, higher priority interrupt handling or critical sections with irqs disabled) when our interrupts arrive - Linux is not a realtime OS.
Agreed. But I think the required precision is in the range of 10 scan lines, i.e. 130µs.
That said we already use similar hack to read pandora's touchscreen during vblank to avoid horrible noise we get doing that during active display and it works kind of ok.
- modify VBP setting of DISPC on the fly (i.e. without disturbing DISPC operation) - register DISPC_TIMING_Vo[31:20] - so that the difference is likely ~0 next time [1][2]
Note that DISPC_TIMING_Vx is a shadow register (hardware only reads it on VFP start), which may cause trouble, but hopefully it would work. Some filter code could be added to deal with latency spikes.
The question will become how that fits into the OMAP DSS driver architecture. Would it become a special mode or a separate „external sync“ driver module? Or should we try to integrate such a function into the ssd2858 panel driver (if possible)?
Sounds like it will be quite horrible with little chance of getting mainlined, so will be a maintenance burden forever either for us or whoever accepts it into mainline. Although it's probably better that out-of-tree pandora's TS hack where I had to fight against linux's driver isolation to get completely unrelated drivers to cooperate.
Anyway this sounds like the least bad solution so far,
:)
the other one being potential use of command mode with TE. Tomi, can command mode be used to achieve steady 60fps?
This would be better of course.
BR, Nikolaus
[1] if that scheme works, two such measurements and an arbitrary initial modification of VBP could allow to calculate the correct VBP value. So I think locking could be done in 2-3 frames.
I think it would need constant adjustment because of OMAP's and SSD's clocks being derived from separate crystals, and the smallest adjustment granularity we has is the whole line or column. The clock frequency difference will slightly differ between different units too, will be affected by temperatures and so on...
[2] it is not necessary to have 0 skew. It must just be small enough so that DISPC buffer swapping occurs during vertical blanking as indicated by the SSD. So I would assume that we have 20-30 lines error bandwidth. So interrupt context switch latency in the kernel is also not critical.
We can manipulate this somewhat by choosing large blanking periods, but still drifting needs to be dealt with somehow…
Drifting is accounted for by making it phase locked (and not frequency locked). I.e. if the frequencies disagree by let’s say 0.1 Hz, this might mean 20 lines skew per second. Enough time to regulate the VBP of the intermediate frames.
So I see no problem if the VBP is adjusted every now and then to keep the average frequency the same - and the sync pulses start roughly at the same moment.
Am 10.06.2015 um 17:58 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 8 Jun 2015 11:10:39 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
> We now have enabled a TE impulse from the ssd2858 chip going to > dsiporta_te0 / gpio6_189. > The question is how to enable it on the OMAP5 side. I presume you are using the SSD2858 with DSI video mode input. There's no TE in that case. TE is only for DSI command mode.
I browsed the net quite a bit, trying to find out the differences between video mode, command mode and TE.
If I understand it correctly, TE mode is always only available in command mode (on any SoC, not just on the OMAP). So TE is officially for anti-tearing and only works in command mode - therefore, I wanted to find out what the differences are between video mode and command mode.
I found that site, which does explain it quite good: http://www.electronicproducts.com/Analog_Mixed_Signal_ICs/Communications_Int...
If I understand correctly, video mode is basically the same as the classic way (sending RGB signals). There's always a video stream being sent, usually without an external framebuffer, so unless you use the timings from the video stream, it's not possible to sychronize them (that's why TE doesn't work here).
Command mode has a different approach: It sends the frames as DCS packages to the LCD (or SSD in our case). The SSD/LCD needs to have a framebuffer to store it, displays it autonomously and then sends a TE signal back to the OMAP5 to tell it that the next package can be sent. Additionally, command mode supports stuff like only updating video data when necessary (i.e. if a smartphone shows a website without animation and the user doesn't scroll around, it doesn't to send frame packages and saves power).
First question: Did I understand that correctly, or is there something wrong?
Second question: Can we use the command mode on the OMAP5? Is this implemented in the driver? Does the driver (and the hardware) take care of everything or would we need to fix every program on Linux to make it work with the command mode?
Thanks in advance :)
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 06/11/2015 02:03 PM, Dr. H. Nikolaus Schaller wrote:
Hi,
Am 11.06.2015 um 12:43 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
A few quick notes:
DISPC_TV_FID is something else.
I think I mixed it up with DISPC_TV_VSYNC coming from the HDMI timing generator.
Ok. Yes, DISPC supports external sync, where "external" means outside DISPC but inside DSS =). Although the external sync with DISPC is not something that would work with plain TE signal.
Having that kind of "stretch back porch" would not comply with DSI standard. And, to me, sounds like quite a hack.
Sometimes a working quick hack is more valuable than a good and broad solution that is not available :)
Sure. Feel free to try your quick hack, but it sounds to me like a very complex hack =).
SSD data sheet says it supports video mode and command mode, and it says it support rotation. What you are discussing here is not related to rotation, but “how can video mode be used with SSD".
There is some relation to rotation because rotation means that the HSYNC frequency on the input is different from the HSYNC frequency to the panel. Even if VSYNC is identical. But you are right - keeping input and output in VSYNC is also a problem in non-rotated mode.
The SSD docs should explain how video mode can be used (i.e. how the SSD input and output are syncronized).
They say (and we can confirm) that the SSD generates a TE output signal (even in video mode) and the video source must be synchronized to it…
The TE here is probably directly sourced from the SSD's VSYNC, which exists with video mode also. They just never gate the TE signal. But DSI video mode does not need TE, it's only for command mode. I don't see how SSD can require TE with DSI video mode, and still say they are DSI compliant.
If a device (SSD) supports video mode, it should be able to synchronize with the video input stream. I don’t see how SSD could advertize supporting video mode if it cannot sync with the input.
That would be a “stretch back porch” applied to the SSD output going to the panel.
I think we can pass-through both HSYNC and VSYNC but AFAIK this does not work in combination with rotation (because different HSYNC frequency requirements).
Ok. So it might be that SSD does not support rotation with video mode.
Command mode should work with omapdss. omapfb has ioctl to send a frame. omapdrm doesn't support command mode. The command mode SW implementation is designed so that the expectation is that the userspace explicitly requests a frame to be updated, i.e. there’s no "automatic update" support.
Understood. It looks to me as it makes using it with X11 or Qt a little difficult because AFAIK they expect a simply framebuffer and an auto-updating panel.
Yes, I don't recommend DSI command mode. But it is an option. The driver could be modified to send frames automatically, making DSI command mode look like normal video mode from user's point of view.
Also note that rotation requires double buffering in SSD, i.e. they have 2 x frame memory, update from SoC goes to one, while the other one is being displayed on panel. Presumably it requires config to use double buffering. If you don’t do that, and update the same piece of memory from SoC while it's being displayed, you'll see diagonal tearing.
I think we have enabled that and we see vertical tearing (i.e. the moment where buffers are swapped is not in sync).
And if SSD doesn't have double buffering support, I don't see how they can support rotation (properly).
Tomi
So it might end up that we have to try the second worst solution to sync the VSYNC interrupts by a daemon.
Or could the daemon simply to the same as the command mode ioctl()? I.e. we would trigger it by the panel VSYNC interrupt?
My recommendations for possible solutions:
1) try to use SSD with video mode. Maybe it can take the clock from the DSI video mode input, but you can still define different hsync/vsync/etc for output. That way SSD runs with the clock from OMAP, and they are synchronized, and SSD can still send the output in rotated form. This is how I would've designed the SSD chip, and I've seen similar on other chips.
Or, if it can't take the clock from the input video stream, you may still be able to sync SSD to the input's vsync. This I have also seen on other chips. In this mode the clocks may drift a bit, but as there's a sync point at the start of every frame, it doesn't matter as long as the drift is small.
2) try command mode. if it works flawlessly with SSD, hack the omapdss's dsi driver to continuously send frames.
Btw is there a public doc for the SSD chip?
Tomi
Am Thu, 11 Jun 2015 14:30:19 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Btw is there a public doc for the SSD chip?
No, but I'll send it to you.
On 06/11/2015 02:30 PM, Tomi Valkeinen wrote:
- try to use SSD with video mode. Maybe it can take the clock from the
DSI video mode input, but you can still define different hsync/vsync/etc for output. That way SSD runs with the clock from OMAP, and they are synchronized, and SSD can still send the output in rotated form. This is how I would've designed the SSD chip, and I've seen similar on other chips.
Looking at the SSD doc, I can see that the above should be supported. (I guess it's the MRX bit in SCM PLL register).
But I also see the application note saying that to use rotation, you need TE, etc. The app note doesn't explain why using the DSI input clock won't work, though.
Maybe SSD can use the DSI input clock, but in that case it cannot use custom hsync/vsync/etc for output. That doesn't make any sense, though, as there should be no diff between using SSD's PLL or DSI clock as ref clock.
Do you have contacts in Solomon Systech? Maybe they could confirm if using DSI clock as ref clock, and configuring the output video timings carefully to match the input timings (but rotated), rotation can be used with video mode.
Tomi
Am Thu, 11 Jun 2015 15:51:09 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Thanks. I've forwarded the questions to them, will let you know the reply.
On 06/11/2015 02:30 PM, Tomi Valkeinen wrote:
- try to use SSD with video mode. Maybe it can take the clock from
the DSI video mode input, but you can still define different hsync/vsync/etc for output. That way SSD runs with the clock from OMAP, and they are synchronized, and SSD can still send the output in rotated form. This is how I would've designed the SSD chip, and I've seen similar on other chips.
Looking at the SSD doc, I can see that the above should be supported. (I guess it's the MRX bit in SCM PLL register).
But I also see the application note saying that to use rotation, you need TE, etc. The app note doesn't explain why using the DSI input clock won't work, though.
Maybe SSD can use the DSI input clock, but in that case it cannot use custom hsync/vsync/etc for output. That doesn't make any sense, though, as there should be no diff between using SSD's PLL or DSI clock as ref clock.
Do you have contacts in Solomon Systech? Maybe they could confirm if using DSI clock as ref clock, and configuring the output video timings carefully to match the input timings (but rotated), rotation can be used with video mode.
Tomi _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am Thu, 11 Jun 2015 15:51:09 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Dear Tomi (and all :)),
it took a while, as there first was a bit of confusion between us and Solomon regarding tearing.
Solomon thought we meant signal tearing which would result in random dots on the screen, whereas we were talking about screen tearing (where two frames can be seen at once on the screen).
I then sent them the following details:
------------ SNIP ----------------
okay, I made the video with four different setups. I also attached TXT-Files which include the different settings for both the SSD and OMAP that have been used.
A short summary:
Setup 1: 600mbps with Rotation Setup 2: 600mbps without Rotation
Our old settings: Setup 3: 500mbps without Rotation Setup 4: 500mpbs with Rotation
The LCD alternates between two pictures each five frames. You can clearly see in the video that it shows both frames at the same time when switching, the line where it happens moves. The speed the line moves depends on the various settings - with Setup 3 it's actually moving very slowly.
Please note that this line is ALWAYS in the same direction - it doesn't rotate like the rest of the picture.
Another interesting aspect: With the 600mbps speed setting, random pixels appear on the display (I made a closeup with Setup 2 - you can see them in the black area). With 500mbps, these pixels do not appear.
About the code: I'm no dev, so I don't know what code I should send you. Before I'm sending something wrong: notaz or Nikolaus, can you send him the sourcecodes that are relevant for our setup?
The video can be found here:
http://evildragon.openpandora.org/SSD.mp4
---------- SNAP --------------------
And received the following reply:
---------- SNIP --------------------
I´ve spoken to my team in HK this morning.
So basically, we confirm that your approach is correct. You need to configure the OMAP to sync with the TE pin SSD2858 output sync signal. But we don´t know how do to this because we are not experts on the OMAP. However, this should be straight forward to do because even for RAM diver, OMAP (or any AP), it needs to follow this sync signal to avoid tearing. No matter whether the input to SSD2858 is command mode or video mode, as long as the RAM is in use in 2858, there will be a TE pin output from 2858 to let AP know when it should sync.
I hope this helps.
--------- SNAP --------------------
They didn't answer if the SSD can be set to use Video Stream timings, but reading their answer, I guess it can't do that.
So we need another approach here - the ones we discussed about earlier.
Tomi, what do you think would be easier to implement? Using Command Mode (and patch it so it updates each frame) or the other workaround Nikolaus suggested (to simulate the TE signal with Video Mode?
Additionally, do you know someone who could help us implement that, preferably someone who knows MIPI well? notaz doesn't have much time sadly, and he's not much into MIPI so would need to work himself into it.
I'm happy to either pay that person for the job and / or send Pyra Prototypes, etc. to work with.
If you would like to try, of course, I'd be happy to provide you with anything you like as well (you already deserve at least a Pyra prototype for the help you already have given us).
Prototypes should be available early August. We should try to get the SSD running tear-free until about October.
What do you think? Thanks again :)
Am Thu, 18 Jun 2015 15:09:31 +0200 hat Michael Mrozek mrozek@openpandora.org geschrieben:
Hi Tomi,
another quick addition from Solomon:
----- SNIP -----------
Dear All,
Feedback from my FAE is as follows :
- user programmed parameters: 0x2014 (HT, HDPS), 0x2018 (VT, VDPS), 0x600C (H/VBP, H/VSA), 0x6010 (VACT, H/VFP), 0x6084 (HACT) - on-chip PLL: PLL-> SYSCLK -> PCLK - SSD2848 can support TE for all RAM use-case. TE is only used one-time in Video (into RAM) mode, as compared to every frame in COMMAND Mode. Once both ext vsync and int vsync are aligned at the very start, it would be aligned all the way, because we have satisfy the 2 conditions of 1) AP pixel-clock = SSD pixel-clock, 2) the video timing parameters (i.e. htotal, vtotal) are exactly the same
Please check with customer if he can do below approach OMAP provide the reference clock to SSD instead of using the crystal clock (ranging from 20MHz to 30MHz). This reference clock provided by OMAP should be the same(or derived) reference clock that generate their internal pixel clock. At the end, we need to have the same pixel clock running in both OMAP and SSD2848. Then by programming the exact HTOTAL and VTOTAL at both sides, we would not have any drifting. Then, OMAP needs to make sure it can start their video framing (first frame) in our vertical blanking. This can be done by receiving the TE signal from our side to trigger their on-chip interrupt and after a fine-tuned amount of delay, start their video generation
I hope this helps!
------ SNAP ---------
Nikolaus thinks the better approach is a way to keep it constantly in sync though, so we won't have a drift.
Am Thu, 11 Jun 2015 15:51:09 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Dear Tomi (and all :)),
it took a while, as there first was a bit of confusion between us and Solomon regarding tearing.
Solomon thought we meant signal tearing which would result in random dots on the screen, whereas we were talking about screen tearing (where two frames can be seen at once on the screen).
I then sent them the following details:
------------ SNIP ----------------
okay, I made the video with four different setups. I also attached TXT-Files which include the different settings for both the SSD and OMAP that have been used.
A short summary:
Setup 1: 600mbps with Rotation Setup 2: 600mbps without Rotation
Our old settings: Setup 3: 500mbps without Rotation Setup 4: 500mpbs with Rotation
The LCD alternates between two pictures each five frames. You can clearly see in the video that it shows both frames at the same time when switching, the line where it happens moves. The speed the line moves depends on the various settings - with Setup 3 it's actually moving very slowly.
Please note that this line is ALWAYS in the same direction - it doesn't rotate like the rest of the picture.
Another interesting aspect: With the 600mbps speed setting, random pixels appear on the display (I made a closeup with Setup 2 - you can see them in the black area). With 500mbps, these pixels do not appear.
About the code: I'm no dev, so I don't know what code I should send you. Before I'm sending something wrong: notaz or Nikolaus, can you send him the sourcecodes that are relevant for our setup?
The video can be found here:
http://evildragon.openpandora.org/SSD.mp4
---------- SNAP --------------------
And received the following reply:
---------- SNIP --------------------
I´ve spoken to my team in HK this morning.
So basically, we confirm that your approach is correct. You need to configure the OMAP to sync with the TE pin SSD2858 output sync signal. But we don´t know how do to this because we are not experts on the OMAP. However, this should be straight forward to do because even for RAM diver, OMAP (or any AP), it needs to follow this sync signal to avoid tearing. No matter whether the input to SSD2858 is command mode or video mode, as long as the RAM is in use in 2858, there will be a TE pin output from 2858 to let AP know when it should sync.
I hope this helps.
--------- SNAP --------------------
They didn't answer if the SSD can be set to use Video Stream timings, but reading their answer, I guess it can't do that.
So we need another approach here - the ones we discussed about earlier.
Tomi, what do you think would be easier to implement? Using Command Mode (and patch it so it updates each frame) or the other workaround Nikolaus suggested (to simulate the TE signal with Video Mode?
Additionally, do you know someone who could help us implement that, preferably someone who knows MIPI well? notaz doesn't have much time sadly, and he's not much into MIPI so would need to work himself into it.
I'm happy to either pay that person for the job and / or send Pyra Prototypes, etc. to work with.
If you would like to try, of course, I'd be happy to provide you with anything you like as well (you already deserve at least a Pyra prototype for the help you already have given us).
Prototypes should be available early August. We should try to get the SSD running tear-free until about October.
What do you think? Thanks again :)
Hi,
I didn't decipher the register values they give, but I think they don't seem to answer the questions:
1) can DSI input clock can be used as SSD refclock (thus there's no clock drift) 2) can DSI input sync can be used for the output sync (thus there's no need for TE, and the SoC is driving the sync)
I think 1) is possible, at least according to their documents. About 2) I don't know.
If those are not possible, then I'd go with DSI command mode, and modify the driver to do the updates automatically.
Maybe it's possible to use DSI video mode, and somehow try to adjust the sync in SW, based on the TE signals. But my gut feeling says that it's not an easy option.
Actually, if 1) is possible, maybe it's enough to start the DSI video stream when the first TE arrives. That way there's no clock drift, and if the SW and HW manage to start the video stream quickly enough, it might be inside the time window.
Tomi
On 19/06/15 15:56, Michael Mrozek wrote:
Am Thu, 18 Jun 2015 15:09:31 +0200 hat Michael Mrozek mrozek@openpandora.org geschrieben:
Hi Tomi,
another quick addition from Solomon:
----- SNIP -----------
Dear All,
Feedback from my FAE is as follows :
- user programmed parameters: 0x2014 (HT, HDPS), 0x2018 (VT, VDPS), 0x600C (H/VBP, H/VSA), 0x6010 (VACT, H/VFP), 0x6084 (HACT)
- on-chip PLL: PLL-> SYSCLK -> PCLK
- SSD2848 can support TE for all RAM use-case. TE is only used one-time in Video (into RAM) mode, as compared to every frame in COMMAND Mode. Once both ext vsync and int vsync are aligned at the very start, it would be aligned all the way, because we have satisfy the 2 conditions of 1) AP pixel-clock = SSD pixel-clock, 2) the video timing parameters (i.e. htotal, vtotal) are exactly the same
Please check with customer if he can do below approach OMAP provide the reference clock to SSD instead of using the crystal clock (ranging from 20MHz to 30MHz). This reference clock provided by OMAP should be the same(or derived) reference clock that generate their internal pixel clock. At the end, we need to have the same pixel clock running in both OMAP and SSD2848. Then by programming the exact HTOTAL and VTOTAL at both sides, we would not have any drifting. Then, OMAP needs to make sure it can start their video framing (first frame) in our vertical blanking. This can be done by receiving the TE signal from our side to trigger their on-chip interrupt and after a fine-tuned amount of delay, start their video generation
I hope this helps!
------ SNAP ---------
Nikolaus thinks the better approach is a way to keep it constantly in sync though, so we won't have a drift.
Am Thu, 11 Jun 2015 15:51:09 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Dear Tomi (and all :)),
it took a while, as there first was a bit of confusion between us and Solomon regarding tearing.
Solomon thought we meant signal tearing which would result in random dots on the screen, whereas we were talking about screen tearing (where two frames can be seen at once on the screen).
I then sent them the following details:
------------ SNIP ----------------
okay, I made the video with four different setups. I also attached TXT-Files which include the different settings for both the SSD and OMAP that have been used.
A short summary:
Setup 1: 600mbps with Rotation Setup 2: 600mbps without Rotation
Our old settings: Setup 3: 500mbps without Rotation Setup 4: 500mpbs with Rotation
The LCD alternates between two pictures each five frames. You can clearly see in the video that it shows both frames at the same time when switching, the line where it happens moves. The speed the line moves depends on the various settings - with Setup 3 it's actually moving very slowly.
Please note that this line is ALWAYS in the same direction - it doesn't rotate like the rest of the picture.
Another interesting aspect: With the 600mbps speed setting, random pixels appear on the display (I made a closeup with Setup 2 - you can see them in the black area). With 500mbps, these pixels do not appear.
About the code: I'm no dev, so I don't know what code I should send you. Before I'm sending something wrong: notaz or Nikolaus, can you send him the sourcecodes that are relevant for our setup?
The video can be found here:
http://evildragon.openpandora.org/SSD.mp4
---------- SNAP --------------------
And received the following reply:
---------- SNIP --------------------
I´ve spoken to my team in HK this morning.
So basically, we confirm that your approach is correct. You need to configure the OMAP to sync with the TE pin SSD2858 output sync signal. But we don´t know how do to this because we are not experts on the OMAP. However, this should be straight forward to do because even for RAM diver, OMAP (or any AP), it needs to follow this sync signal to avoid tearing. No matter whether the input to SSD2858 is command mode or video mode, as long as the RAM is in use in 2858, there will be a TE pin output from 2858 to let AP know when it should sync.
I hope this helps.
--------- SNAP --------------------
They didn't answer if the SSD can be set to use Video Stream timings, but reading their answer, I guess it can't do that.
So we need another approach here - the ones we discussed about earlier.
Tomi, what do you think would be easier to implement? Using Command Mode (and patch it so it updates each frame) or the other workaround Nikolaus suggested (to simulate the TE signal with Video Mode?
Additionally, do you know someone who could help us implement that, preferably someone who knows MIPI well? notaz doesn't have much time sadly, and he's not much into MIPI so would need to work himself into it.
I'm happy to either pay that person for the job and / or send Pyra Prototypes, etc. to work with.
If you would like to try, of course, I'd be happy to provide you with anything you like as well (you already deserve at least a Pyra prototype for the help you already have given us).
Prototypes should be available early August. We should try to get the SSD running tear-free until about October.
What do you think? Thanks again :)
Hi Tomi,
Am 24.06.2015 um 14:14 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
Hi,
I didn't decipher the register values they give, but I think they don't seem to answer the questions:
- can DSI input clock can be used as SSD refclock (thus there's no
clock drift) 2) can DSI input sync can be used for the output sync (thus there's no need for TE, and the SoC is driving the sync)
I think 1) is possible, at least according to their documents.
Yes they said that - but if I remember correctly they mentioned it only for non-rotated image.
About 2) I don't know.
If those are not possible, then I'd go with DSI command mode, and modify the driver to do the updates automatically.
I assume this would mean that a TE-interrupt from the SSD does the same as the command mode ioctl(). Could you provide a hint in which source file such an ioctl() is processed?
Maybe it's possible to use DSI video mode, and somehow try to adjust the sync in SW, based on the TE signals. But my gut feeling says that it's not an easy option.
That is what I propose as a closed control loop around both VSYNC signals and to adjust the vertical timing. It is what an old fashioned TV set did do using vacuum tubes :) Well, not exactly. The vertical trace did run autonomously a little slower than required and a received VSYNC tried to speed it up.
Actually, if 1) is possible, maybe it's enough to start the DSI video stream when the first TE arrives. That way there's no clock drift, and if the SW and HW manage to start the video stream quickly enough, it might be inside the time window.
For me there are too many „if“s in this (does it start quickly enough?) and therefore I think a control loop is easier to implement (if it is not quickly on the first TE it might be on the second or third - and minor clock drift is nothing to care about at all). And this may even be beneficial for other systems.
I hope that I find time in some weeks to work on it.
BR, Nikolaus
Tomi
On 19/06/15 15:56, Michael Mrozek wrote:
Am Thu, 18 Jun 2015 15:09:31 +0200 hat Michael Mrozek mrozek@openpandora.org geschrieben:
Hi Tomi,
another quick addition from Solomon:
----- SNIP -----------
Dear All,
Feedback from my FAE is as follows :
- user programmed parameters: 0x2014 (HT, HDPS), 0x2018 (VT, VDPS),
0x600C (H/VBP, H/VSA), 0x6010 (VACT, H/VFP), 0x6084 (HACT)
- on-chip PLL: PLL-> SYSCLK -> PCLK
- SSD2848 can support TE for all RAM use-case. TE is only used
one-time in Video (into RAM) mode, as compared to every frame in COMMAND Mode. Once both ext vsync and int vsync are aligned at the very start, it would be aligned all the way, because we have satisfy the 2 conditions of 1) AP pixel-clock = SSD pixel-clock, 2) the video timing parameters (i.e. htotal, vtotal) are exactly the same
Please check with customer if he can do below approach OMAP provide the reference clock to SSD instead of using the crystal clock (ranging from 20MHz to 30MHz). This reference clock provided by OMAP should be the same(or derived) reference clock that generate their internal pixel clock. At the end, we need to have the same pixel clock running in both OMAP and SSD2848. Then by programming the exact HTOTAL and VTOTAL at both sides, we would not have any drifting. Then, OMAP needs to make sure it can start their video framing (first frame) in our vertical blanking. This can be done by receiving the TE signal from our side to trigger their on-chip interrupt and after a fine-tuned amount of delay, start their video generation
I hope this helps!
------ SNAP ---------
Nikolaus thinks the better approach is a way to keep it constantly in sync though, so we won't have a drift.
Am Thu, 11 Jun 2015 15:51:09 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Dear Tomi (and all :)),
it took a while, as there first was a bit of confusion between us and Solomon regarding tearing.
Solomon thought we meant signal tearing which would result in random dots on the screen, whereas we were talking about screen tearing (where two frames can be seen at once on the screen).
I then sent them the following details:
------------ SNIP ----------------
okay, I made the video with four different setups. I also attached TXT-Files which include the different settings for both the SSD and OMAP that have been used.
A short summary:
Setup 1: 600mbps with Rotation Setup 2: 600mbps without Rotation
Our old settings: Setup 3: 500mbps without Rotation Setup 4: 500mpbs with Rotation
The LCD alternates between two pictures each five frames. You can clearly see in the video that it shows both frames at the same time when switching, the line where it happens moves. The speed the line moves depends on the various settings - with Setup 3 it's actually moving very slowly.
Please note that this line is ALWAYS in the same direction - it doesn't rotate like the rest of the picture.
Another interesting aspect: With the 600mbps speed setting, random pixels appear on the display (I made a closeup with Setup 2 - you can see them in the black area). With 500mbps, these pixels do not appear.
About the code: I'm no dev, so I don't know what code I should send you. Before I'm sending something wrong: notaz or Nikolaus, can you send him the sourcecodes that are relevant for our setup?
The video can be found here:
http://evildragon.openpandora.org/SSD.mp4
---------- SNAP --------------------
And received the following reply:
---------- SNIP --------------------
I´ve spoken to my team in HK this morning.
So basically, we confirm that your approach is correct. You need to configure the OMAP to sync with the TE pin SSD2858 output sync signal. But we don´t know how do to this because we are not experts on the OMAP. However, this should be straight forward to do because even for RAM diver, OMAP (or any AP), it needs to follow this sync signal to avoid tearing. No matter whether the input to SSD2858 is command mode or video mode, as long as the RAM is in use in 2858, there will be a TE pin output from 2858 to let AP know when it should sync.
I hope this helps.
--------- SNAP --------------------
They didn't answer if the SSD can be set to use Video Stream timings, but reading their answer, I guess it can't do that.
So we need another approach here - the ones we discussed about earlier.
Tomi, what do you think would be easier to implement? Using Command Mode (and patch it so it updates each frame) or the other workaround Nikolaus suggested (to simulate the TE signal with Video Mode?
Additionally, do you know someone who could help us implement that, preferably someone who knows MIPI well? notaz doesn't have much time sadly, and he's not much into MIPI so would need to work himself into it.
I'm happy to either pay that person for the job and / or send Pyra Prototypes, etc. to work with.
If you would like to try, of course, I'd be happy to provide you with anything you like as well (you already deserve at least a Pyra prototype for the help you already have given us).
Prototypes should be available early August. We should try to get the SSD running tear-free until about October.
What do you think? Thanks again :)
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 24/06/15 15:42, Dr. H. Nikolaus Schaller wrote:
Hi Tomi,
Am 24.06.2015 um 14:14 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
Hi,
I didn't decipher the register values they give, but I think they don't seem to answer the questions:
- can DSI input clock can be used as SSD refclock (thus there's no
clock drift) 2) can DSI input sync can be used for the output sync (thus there's no need for TE, and the SoC is driving the sync)
I think 1) is possible, at least according to their documents.
Yes they said that - but if I remember correctly they mentioned it only for non-rotated image.
Ok. Well, I don't see how it could work only for non-rotated. It's just refclock, the rotation engine shouldn't care where the refclock comes from.
About 2) I don't know.
If those are not possible, then I'd go with DSI command mode, and modify the driver to do the updates automatically.
I assume this would mean that a TE-interrupt from the SSD does the same as the command mode ioctl(). Could you provide a hint in which source file such
Yes.
an ioctl() is processed?
At the moment only the omapfb with OMAPFB_UPDATE_WINDOW ioctl (drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c) supports update from userspace.
I think the SSD driver could call update() from the omapdss_dsi_ops when it gets TE interrupt. You could have a look at drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c, which does update but not automatically.
It's possible that this is all that's needed if you want to use omapfb. At the moment omapdrm doesn't support manual updates, so there's more work to be done there.
Tomi
Hi Tomi,
an ioctl() is processed?
At the moment only the omapfb with OMAPFB_UPDATE_WINDOW ioctl (drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c) supports update from userspace.
I think the SSD driver could call update() from the omapdss_dsi_ops when it gets TE interrupt. You could have a look at drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c, which does update but not automatically.
It's possible that this is all that's needed if you want to use omapfb. At the moment omapdrm doesn't support manual updates, so there's more work to be done there.
I think that's perfect for testing the hardware really works fine for the beginning.
However, I guess we need to move to omapdrm over time, as far as I know the SGX has only be compiled to be used with omapdrm, not omapfb, correct?
On 24/06/15 16:13, Michael Mrozek wrote:
Hi Tomi,
an ioctl() is processed?
At the moment only the omapfb with OMAPFB_UPDATE_WINDOW ioctl (drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c) supports update from userspace.
I think the SSD driver could call update() from the omapdss_dsi_ops when it gets TE interrupt. You could have a look at drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c, which does update but not automatically.
It's possible that this is all that's needed if you want to use omapfb. At the moment omapdrm doesn't support manual updates, so there's more work to be done there.
I think that's perfect for testing the hardware really works fine for the beginning.
However, I guess we need to move to omapdrm over time, as far as I know the SGX has only be compiled to be used with omapdrm, not omapfb, correct?
SGX has been used with both. The omapdrm + SGX combination has done a better job, though. Then again, at the moment mainline omapdrm can't probably be used with SGX, with the large atomic modesetting changes.
Tomi
Hi,
On 06/24/2015 04:25 PM, Tomi Valkeinen wrote:
On 24/06/15 16:13, Michael Mrozek wrote:
However, I guess we need to move to omapdrm over time, as far as I know the SGX has only be compiled to be used with omapdrm, not omapfb, correct?
SGX has been used with both. The omapdrm + SGX combination has done a better job, though. Then again, at the moment mainline omapdrm can't probably be used with SGX, with the large atomic modesetting changes.
Yes but it can only use both omapfb and omapdrm only on OMAP3. The OMAP5 blobs have hard dependency on DRM. Or am I missing anything?
Your news that the blobs lost compatibility with latest mainline are really bad :( Have you heard any TI's plans about ever updating SGX blobs for OMAP5? Their latest release supporting OMAP5 is back from 2013...
Grazvydas
On 24/06/15 16:52, Grazvydas Ignotas wrote:
Hi,
On 06/24/2015 04:25 PM, Tomi Valkeinen wrote:
On 24/06/15 16:13, Michael Mrozek wrote:
However, I guess we need to move to omapdrm over time, as far as I know the SGX has only be compiled to be used with omapdrm, not omapfb, correct?
SGX has been used with both. The omapdrm + SGX combination has done a better job, though. Then again, at the moment mainline omapdrm can't probably be used with SGX, with the large atomic modesetting changes.
Yes but it can only use both omapfb and omapdrm only on OMAP3. The OMAP5 blobs have hard dependency on DRM. Or am I missing anything?
I haven't used the blobs out there, so you're probably right. I do know it's possible to compile the SGX driver/libs to use either omapfb or omapdrm.
Your news that the blobs lost compatibility with latest mainline are
Correct me if I'm wrong, but I don't think the mainline has ever been compatible with the SGX driver. There's always been some additional patches needed for omapdrm. At least this has been the case on the platforms I've worked on.
SGX will always be a huge pain in the ass, as long as it's closed source with no stable API towards the HW.
To be honest, I'm not sure if the compatibility has been broken. It could be, it could be not. We wanted to proceed with omapdrm modernization and cleanup, to get atomic modesetting and dmabuf fences supported, and build SGX support on top of those for a new SGX DDK. So we decided not to try too much to keep compatibility with old binary blobs out there.
really bad :( Have you heard any TI's plans about ever updating SGX blobs for OMAP5? Their latest release supporting OMAP5 is back from 2013...
For OMAP5, probably no plans. But I think OMAP5 has the same SGX as DRA7 and AM5, so when we get the new DDK working on DRA7 and AM5, it might work with OMAP5.
Tomi
Am Wed, 24 Jun 2015 17:42:04 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
really bad :( Have you heard any TI's plans about ever updating SGX blobs for OMAP5? Their latest release supporting OMAP5 is back from 2013...
For OMAP5, probably no plans. But I think OMAP5 has the same SGX as DRA7 and AM5, so when we get the new DDK working on DRA7 and AM5, it might work with OMAP5.
Isn't the AM5 basically the same as the OMAP5, just with enhanced DSPs (the ones the OMAP3 had)?
I wonder how compatible the hardware design is...
BTW: Right now, the OMAP5 EVM only runs with 500, 1000 or 1500 MHz. It seems you can't clock it lower and it can't dynamically switch to other than those three fixed frequencies. Is that something that can be changed? For powersaving, running at 50 MHz sometimes should be enough.
On 24/06/15 18:55, Michael Mrozek wrote:
Am Wed, 24 Jun 2015 17:42:04 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
really bad :( Have you heard any TI's plans about ever updating SGX blobs for OMAP5? Their latest release supporting OMAP5 is back from 2013...
For OMAP5, probably no plans. But I think OMAP5 has the same SGX as DRA7 and AM5, so when we get the new DDK working on DRA7 and AM5, it might work with OMAP5.
Isn't the AM5 basically the same as the OMAP5, just with enhanced DSPs (the ones the OMAP3 had)?
No, I wouldn't call it "basically the same". In this context (DSS & SGX) they are probably close enough, though.
I wonder how compatible the hardware design is...
BTW: Right now, the OMAP5 EVM only runs with 500, 1000 or 1500 MHz. It seems you can't clock it lower and it can't dynamically switch to other than those three fixed frequencies. Is that something that can be changed? For powersaving, running at 50 MHz sometimes should be enough.
I don't really know, but I don't think so.
Tomi
On 24/06/15 17:42, Tomi Valkeinen wrote:
really bad :( Have you heard any TI's plans about ever updating SGX blobs for OMAP5? Their latest release supporting OMAP5 is back from 2013...
For OMAP5, probably no plans. But I think OMAP5 has the same SGX as DRA7 and AM5, so when we get the new DDK working on DRA7 and AM5, it might work with OMAP5.
I discussed this with our gfx guy, and OMAP5 is officially in legacy mode. However, we think it should be easy to create binary blobs for omap5 also (probably the same blobs work for DRA7, AM5, OMAP5), and we will try to test OMAP5 also when we get the new DDK working on AM5 and DRA7.
So no promises, and the ETA for this is maybe late this year, early 2016.
Tomi
Am Wed, 24 Jun 2015 14:42:05 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
I didn't decipher the register values they give, but I think they don't seem to answer the questions:
- can DSI input clock can be used as SSD refclock (thus there's no
clock drift) 2) can DSI input sync can be used for the output sync (thus there's no need for TE, and the SoC is driving the sync) I think 1) is possible, at least according to their documents.
Yes they said that - but if I remember correctly they mentioned it only for non-rotated image.
Yes, for rotated image, TE signal is needed.
Actually, if 1) is possible, maybe it's enough to start the DSI video stream when the first TE arrives. That way there's no clock drift, and if the SW and HW manage to start the video stream quickly enough, it might be inside the time window.
For me there are too many „if“s in this (does it start quickly enough?) and therefore I think a control loop is easier to implement (if it is not quickly on the first TE it might be on the second or third - and minor clock drift is nothing to care about at all). And this may even be beneficial for other systems.
Well, isn't that what they actually suggested to us as well?
---- SNIP -------------------
Feedback from my FAE is as follows :
- user programmed parameters: 0x2014 (HT, HDPS), 0x2018 (VT, VDPS), 0x600C (H/VBP, H/VSA), 0x6010 (VACT, H/VFP), 0x6084 (HACT) - on-chip PLL: PLL-> SYSCLK -> PCLK - SSD2848 can support TE for all RAM use-case. TE is only used one-time in Video (into RAM) mode, as compared to every frame in COMMAND Mode. Once both ext vsync and int vsync are aligned at the very start, it would be aligned all the way, because we have satisfy the 2 conditions of 1) AP pixel-clock = SSD pixel-clock, 2) the video timing parameters (i.e. htotal, vtotal) are exactly the same
---- SNAP --------------------
A one-time TE-signal and then use the exact same settings.
If this is easy to do, I so no harm in trying it. Just start it, let the display work for one day and see whether it's still in sync.
I hope that I find time in some weeks to work on it.
BR, Nikolaus
Tomi
On 19/06/15 15:56, Michael Mrozek wrote:
Am Thu, 18 Jun 2015 15:09:31 +0200 hat Michael Mrozek mrozek@openpandora.org geschrieben:
Hi Tomi,
another quick addition from Solomon:
----- SNIP -----------
Dear All,
Feedback from my FAE is as follows :
- user programmed parameters: 0x2014 (HT, HDPS), 0x2018 (VT, VDPS),
0x600C (H/VBP, H/VSA), 0x6010 (VACT, H/VFP), 0x6084 (HACT)
- on-chip PLL: PLL-> SYSCLK -> PCLK
- SSD2848 can support TE for all RAM use-case. TE is only used
one-time in Video (into RAM) mode, as compared to every frame in COMMAND Mode. Once both ext vsync and int vsync are aligned at the very start, it would be aligned all the way, because we have satisfy the 2 conditions of 1) AP pixel-clock = SSD pixel-clock, 2) the video timing parameters (i.e. htotal, vtotal) are exactly the same
Please check with customer if he can do below approach OMAP provide the reference clock to SSD instead of using the crystal clock (ranging from 20MHz to 30MHz). This reference clock provided by OMAP should be the same(or derived) reference clock that generate their internal pixel clock. At the end, we need to have the same pixel clock running in both OMAP and SSD2848. Then by programming the exact HTOTAL and VTOTAL at both sides, we would not have any drifting. Then, OMAP needs to make sure it can start their video framing (first frame) in our vertical blanking. This can be done by receiving the TE signal from our side to trigger their on-chip interrupt and after a fine-tuned amount of delay, start their video generation
I hope this helps!
------ SNAP ---------
Nikolaus thinks the better approach is a way to keep it constantly in sync though, so we won't have a drift.
Am Thu, 11 Jun 2015 15:51:09 +0300 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Dear Tomi (and all :)),
it took a while, as there first was a bit of confusion between us and Solomon regarding tearing.
Solomon thought we meant signal tearing which would result in random dots on the screen, whereas we were talking about screen tearing (where two frames can be seen at once on the screen).
I then sent them the following details:
------------ SNIP ----------------
okay, I made the video with four different setups. I also attached TXT-Files which include the different settings for both the SSD and OMAP that have been used.
A short summary:
Setup 1: 600mbps with Rotation Setup 2: 600mbps without Rotation
Our old settings: Setup 3: 500mbps without Rotation Setup 4: 500mpbs with Rotation
The LCD alternates between two pictures each five frames. You can clearly see in the video that it shows both frames at the same time when switching, the line where it happens moves. The speed the line moves depends on the various settings - with Setup 3 it's actually moving very slowly.
Please note that this line is ALWAYS in the same direction - it doesn't rotate like the rest of the picture.
Another interesting aspect: With the 600mbps speed setting, random pixels appear on the display (I made a closeup with Setup 2 - you can see them in the black area). With 500mbps, these pixels do not appear.
About the code: I'm no dev, so I don't know what code I should send you. Before I'm sending something wrong: notaz or Nikolaus, can you send him the sourcecodes that are relevant for our setup?
The video can be found here:
http://evildragon.openpandora.org/SSD.mp4
---------- SNAP --------------------
And received the following reply:
---------- SNIP --------------------
I´ve spoken to my team in HK this morning.
So basically, we confirm that your approach is correct. You need to configure the OMAP to sync with the TE pin SSD2858 output sync signal. But we don´t know how do to this because we are not experts on the OMAP. However, this should be straight forward to do because even for RAM diver, OMAP (or any AP), it needs to follow this sync signal to avoid tearing. No matter whether the input to SSD2858 is command mode or video mode, as long as the RAM is in use in 2858, there will be a TE pin output from 2858 to let AP know when it should sync.
I hope this helps.
--------- SNAP --------------------
They didn't answer if the SSD can be set to use Video Stream timings, but reading their answer, I guess it can't do that.
So we need another approach here - the ones we discussed about earlier.
Tomi, what do you think would be easier to implement? Using Command Mode (and patch it so it updates each frame) or the other workaround Nikolaus suggested (to simulate the TE signal with Video Mode?
Additionally, do you know someone who could help us implement that, preferably someone who knows MIPI well? notaz doesn't have much time sadly, and he's not much into MIPI so would need to work himself into it.
I'm happy to either pay that person for the job and / or send Pyra Prototypes, etc. to work with.
If you would like to try, of course, I'd be happy to provide you with anything you like as well (you already deserve at least a Pyra prototype for the help you already have given us).
Prototypes should be available early August. We should try to get the SSD running tear-free until about October.
What do you think? Thanks again :)
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel