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