Hi,
One thing comes to my mind: Could the difference be that with our hacky script the MIPI stream from the OMAP is already initialized (meaning: when you enable the SSD with the script it receives a proper video stream) whereas there's no video stream being sent already when you start the SSD as kernel module?
Maybe the SSD reads the video stream details as soon as it is enabled and has improper values if there's no existing video stream, causing it to run completely unsynchronized?
On May 10, 2016 5:41:35 PM GMT+02:00, "H. Nikolaus Schaller" hns@goldelico.com wrote:
Hi Tomi,
Am 10.05.2016 um 14:29 schrieb Tomi Valkeinen
On 28/04/16 16:05, H. Nikolaus Schaller wrote:
Hi,
Am 28.04.2016 um 14:16 schrieb Michael Mrozek
Am Thu, 28 Apr 2016 10:00:03 +0200 hat H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
Shouldn't Linux find a 1280x720 screen mode when the rotator is working properly?
This appears to report the resolution for the connector (= panel).
That's what I thought.
Ok, this looks indeed to be wrong. Hm. How can we "manipulate"
that
without touching the panel driver? Probably only if we make the
ssd
chip the panel and remove the real panel from the display aliases?
Yes, I think that's the best solution (and what I suggested before
we
even received the first sample of the SSD :D)
Well, that was pure luck to make the right prognosis. Was a 50:50
chance :)
For the TV-Out (Pandora) or other chips it is not a problem.
What the real problem is that I want a panel driver and a separate
ssd
driver while your architecture suggests a combo driver which mixes
everything.
I haven't been able to follow the discussion here (and please To: or
Cc:
me if you want my reply, I won't notice the emails sent only to pyra list),
no problem. At the moment I think it is not a general omapdss problem but something in controlling the ssd chip correctly where you could only help if you had a piece of hardware to run tests.
but one thing to consider:
The current panel/encoder model is omap specific, and should be
thrown
away as soon as possible.
Agreed. I was contacted recently by a team that wanted to hire me to write a driver for the ssd2858 to connect to a snapdragon. But that would mean a complete rewrite IMHO.
For this reason, I'm very reluctant to merge any new omap specific panels/encoders to upstream.
Also no problem. We need a working driver first before we think about upstreaming :) If we have such a reference driver it can be used as a starting (and benchmark) for any new type of drivers.
I'm not sure when this work to move to common DRM panels/encoders
will
happen (and it's a big one), but for the time being, if it makes your case easier, I think you should just go with a "combined" driver,
which
has both SSD and the panel drivers in one.
I can simulate such a setup if I "disable" the panel driver or make it not send DCS commands.
And if I disable the ssd side and use a display board without ssd chip installed (but MIPI signals bridged in hardware), the panel driver works even in our two-staged setup.
It's not 100% correct approach, but if it makes the display work
easier,
I recommend that approach instead of trying to create a perfect
driver
(which can't be upstreamed).
I think that the problem is not that we have two interacting drivers. They appear to interact perfectly and now seem to do what they should do (with backwards and forward calls).
The problem is that if I read out the ssd2858 registers and the ompadss debugfs I can't find a significant difference to our working hack with the mipi-debug driver + shell script. But it works only with the hack.
So the only idea not fully tested is some timing and sequence issue with chip reset and turning on/off dsi and video streams.
And another idea is that it has something to do with the "atomic timeouts" we see in the working driver.
I have checked recently and this means that some dss update should wait until a vertical retrace interrupt. Seeing "atomic timeouts" means that some actions occur too fast before the previous one was finished.
But these messages are not triggered by the driver or the dss subsystem. They are triggered as soon as X11 wants to initialize.
So this means that the mipi-panel-debug driver + shell script violates some condition - which might be exactly what the ssd chip needs to work...
BR, Nikolaus