Hi, for the records...
I have checked the hardware with the new R63311 data sheet and did not find issues.
The panel is wired as "VSP and VSN: External supply Method" (Fig. 3 on page 26)
Except that there is a DBIST input hard wired to "0". It can be interpreted as disabling the test pattern mode completely - or it can be interpreted as not enabling it unless software does.
Then, I did check and verify the capacitors we find external to the controller chip on the panel's fFPC. All voltages fit to the data sheet and appear to be ok (what I don't know is if +/- 6.5V is the right voltage to drive the liquid crystal - but I assume it is ok).
I should also note that the charge pump stops if I issue the 10h DCS command and most voltages are switched off.
Since 1. there are not many other pins on the display connector and 2. I have checked the data/clock lanes for correct assignment and 3, we can read/write DCS commands, I conclude that it is very unlikely that we still have an undetected hardware error on our adapter.
Another though on the pattern we see. It is comprised of fine vertical stripes - but all in grey. I did now understand that the R63311 chip has 1080 output drivers and those are most likeley driving the *columns*. So if we see *rows* of stripes this would mean that the panel is vertically scanning - but the 1080 column values all have constant output signals.
What could that mean? Maybe that our horizontal sync is not working properly. So even if we send data to the panel in RGB lines, the drivers are not changed/updated as needed.
This could have several reasons: * we do not have hsync bursts in the video data (so that the panel is not switching to the next line) * the timing of the hsync bursts may be wrong in relation to what the R63311 can accept * the washing out effect of the corners may also come from such a missing hsync (since a panel usually inverts the voltage after each full frame)
So again some more ideas where to look into.
Note: this all does not explain why I can't read the BFH chip id data through DCS.
Some interesting news!
Am 05.03.2014 um 12:40 schrieb Dr. H. Nikolaus Schaller:
Hi, for the records...
I have checked the hardware with the new R63311 data sheet and did not find issues.
The panel is wired as "VSP and VSN: External supply Method" (Fig. 3 on page 26)
Except that there is a DBIST input hard wired to "0". It can be interpreted as disabling the test pattern mode completely - or it can be interpreted as not enabling it unless software does.
Then, I did check and verify the capacitors we find external to the controller chip on the panel's fFPC. All voltages fit to the data sheet and appear to be ok (what I don't know is if +/- 6.5V is the right voltage to drive the liquid crystal - but I assume it is ok).
I should also note that the charge pump stops if I issue the 10h DCS command and most voltages are switched off.
Since
- there are not many other pins on the display connector and
- I have checked the data/clock lanes for correct assignment and
3, we can read/write DCS commands, I conclude that it is very unlikely that we still have an undetected hardware error on our adapter.
Another though on the pattern we see. It is comprised of fine vertical stripes - but all in grey. I did now understand that the R63311 chip has 1080 output drivers and those are most likeley driving the *columns*. So if we see *rows* of stripes this would mean that the panel is vertically scanning - but the 1080 column values all have constant output signals.
What could that mean? Maybe that our horizontal sync is not working properly. So even if we send data to the panel in RGB lines, the drivers are not changed/updated as needed.
This could have several reasons:
- we do not have hsync bursts in the video data (so that the panel is not switching to the next line)
- the timing of the hsync bursts may be wrong in relation to what the R63311 can accept
- the washing out effect of the corners may also come from such a missing hsync (since a panel usually inverts the voltage after each full frame)
So again some more ideas where to look into.
Note: this all does not explain why I can't read the BFH chip id data through DCS.
I have checked what the initialization code is (trying to) program into the panel:
This means that the Panel voltges should be 9.0 V and not the 6 V I can measure!
The only conclusion I can draw is that the panel is not executing manufacturer specific commands. Neither setting the panel nor reading the chip ID.
But it is handling (most) "standard" DCS commands.
It turns out that it is even worse: if I issue the same write command from the /sys interface (after it had been sent during initialization) - the panel controller gets stuck and non-responsive.
That is really strange but may be a hint where the problem is.
BR, Nikolaus
On Wed, Mar 5, 2014 at 1:40 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Another though on the pattern we see. It is comprised of fine vertical stripes - but all in grey. I did now understand that the R63311 chip has 1080 output drivers and those are most likeley driving the *columns*. So if we see *rows* of stripes this would mean that the panel is vertically scanning - but the 1080 column values all have constant output signals.
Hmm, so are you trying it with DSS set up to send 1920x1080 landscape image? Maybe it should be set up as 1080x1920 portrait (or reverse)?
Gražvydas
Am 05.03.2014 um 15:02 schrieb Grazvydas Ignotas:
On Wed, Mar 5, 2014 at 1:40 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Another though on the pattern we see. It is comprised of fine vertical stripes - but all in grey. I did now understand that the R63311 chip has 1080 output drivers and those are most likeley driving the *columns*. So if we see *rows* of stripes this would mean that the panel is vertically scanning - but the 1080 column values all have constant output signals.
Hmm, so are you trying it with DSS set up to send 1920x1080 landscape image? Maybe it should be set up as 1080x1920 portrait (or reverse)?
Here is how it is oriented (note that it is a smartphone display):
And the grey stripes are in vertical columns. So all 1920 rows are the same.
BR, Nikolaus
Am Wed, 5 Mar 2014 12:40:49 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
good news - getting the datasheet was pretty essential.
Did you forward this yourself to Timo?
I haven't added him to the mailing list yet (he did not reply whether he wanted or not).
I added DJWillis and skeezix though, welcome you two :)
Hi, for the records...
I have checked the hardware with the new R63311 data sheet and did not find issues.
The panel is wired as "VSP and VSN: External supply Method" (Fig. 3 on page 26)
Except that there is a DBIST input hard wired to "0". It can be interpreted as disabling the test pattern mode completely - or it can be interpreted as not enabling it unless software does.
Then, I did check and verify the capacitors we find external to the controller chip on the panel's fFPC. All voltages fit to the data sheet and appear to be ok (what I don't know is if +/- 6.5V is the right voltage to drive the liquid crystal - but I assume it is ok).
I should also note that the charge pump stops if I issue the 10h DCS command and most voltages are switched off.
Since
- there are not many other pins on the display connector and
- I have checked the data/clock lanes for correct assignment and
3, we can read/write DCS commands, I conclude that it is very unlikely that we still have an undetected hardware error on our adapter.
Another though on the pattern we see. It is comprised of fine vertical stripes - but all in grey. I did now understand that the R63311 chip has 1080 output drivers and those are most likeley driving the *columns*. So if we see *rows* of stripes this would mean that the panel is vertically scanning - but the 1080 column values all have constant output signals.
What could that mean? Maybe that our horizontal sync is not working properly. So even if we send data to the panel in RGB lines, the drivers are not changed/updated as needed.
This could have several reasons:
- we do not have hsync bursts in the video data (so that the panel is
not switching to the next line)
- the timing of the hsync bursts may be wrong in relation to what the
R63311 can accept
- the washing out effect of the corners may also come from such a
missing hsync (since a panel usually inverts the voltage after each full frame)
So again some more ideas where to look into.
Note: this all does not explain why I can't read the BFH chip id data through DCS.
Am 05.03.2014 um 16:08 schrieb Michael Mrozek:
Am Wed, 5 Mar 2014 12:40:49 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
good news - getting the datasheet was pretty essential.
Yes! Test pattern is now working:
So I think if I remove the test pattern we *might* have an image - unless there is some other bug on the OMAP5 MIPI-DSI side. Will see soon.
The issue is that the manufacturer commands are *not* DCS commands. So they must be sent differently to the panel.
The result was that we did not even program a single bit.
Did you forward this yourself to Timo?
Yes.
I haven't added him to the mailing list yet (he did not reply whether he wanted or not).
I added DJWillis and skeezix though, welcome you two :)
Welcome!
Nikolaus
Am 05.03.2014 um 19:22 schrieb Dr. H. Nikolaus Schaller:
Am 05.03.2014 um 16:08 schrieb Michael Mrozek:
Am Wed, 5 Mar 2014 12:40:49 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
good news - getting the datasheet was pretty essential.
Yes! Test pattern is now working:
<DSC01893.jpeg>
So I think if I remove the test pattern we *might* have an image - unless there is some other bug on the OMAP5 MIPI-DSI side. Will see soon.
No, there isn't. It simply works :)
Here are the first picture showing an xterm
The issue is that the manufacturer commands are *not* DCS commands. So they must be sent differently to the panel.
The result was that we did not even program a single bit.
I have committed the now working driver so that you can look into the changes:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=summary
What has to be done next: * the backlight still needs the "enforce by GPIO" mode * the display orientation is portrait and should become landscape (maybe by the GFX pipeline of the OMAP5) * I need to fix the display adapters for Notaz and ED and send them to you so that you can really use the panel (and start to evaluate how well it really works for games) * ED must finally decide to go for it (or start over with a different one) * after the panel decision I can start to complete the design of the next Pyra demonstrator boards (which already should fit into the new case and help to evaluate the CPU module idea)
BR, Nikolaus
BTW: the backlight is quite intense on the backside of the panel (and the edges as you can see on the photo where it illuminates the paper). So we could also use the backlight to illuminate the Pyra Logo on the display lid.
Am Wed, 5 Mar 2014 21:46:47 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
That is perfect, thanks a lot :) Then I'll let MSC know they can continue with the touchscreen.
Could you make a picture of some desktop running on it? I'd like to do a blogpost with that.
And a quick brief explanation what the issue was (not too complex), so I can mention that as well.
Awesome :)
Am 05.03.2014 um 19:22 schrieb Dr. H. Nikolaus Schaller:
Am 05.03.2014 um 16:08 schrieb Michael Mrozek:
Am Wed, 5 Mar 2014 12:40:49 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
good news - getting the datasheet was pretty essential.
Yes! Test pattern is now working:
<DSC01893.jpeg>
So I think if I remove the test pattern we *might* have an image - unless there is some other bug on the OMAP5 MIPI-DSI side. Will see soon.
No, there isn't. It simply works :)
Here are the first picture showing an xterm