Am Sun, 1 Mar 2015 19:08:06 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
- make it work on our setup.
Well, they got it working under Linux with the Raspberry Pi, so it shouldn't be THAT much different, but I'd like to prevent that.
With BOE, we've got great support so far and we know that the panels will stay consistent as they don't sell their production lines. They're the biggest panel delivery service for Samsung. If you got a Samsung Galaxy Note, you've got a BOE panel…
Well, there might be the option to use the other BOE panel we initially did have. I think it was a 680l and I don’t know why they switched it. It has a different controller and connector, but otherwise it looked to be the same to me. At least from the data sheet.
That panel is out of production and has been replaced by the one we're using now, so I doubt we can use that.
So we could switch to OLED when the technology is right when BOE is already our partner - those would be great advantages. Some questions:
- If I understood correctly, the issue is the 0xff sequence.
only the 0xff 12 83 01 sequence is too long for the ssd to forward it to the panel. A 0xff 18 80 or a 0xfe 12 83 01 sequence could be forwarded.
So is this only needed for the initialization routine? Or does this affect changing the gamma curve, bit depth, etc. as well?
- Would it be possible to program the Panel through the SSD?
No. Or we would not have these problems. Basically we just can’t switch the panel to programming mode (the 0xff 12 83 01 sequence) if it is connected behind the ssd.
Ah, okay. The programming mode is also a sequence too long.
If we remove the ssd and do OMAP rotation we have the cheapest variant and it works. Although it drives up processing load of the OMAP.
Which doesn't work properly as we already clarified, so that is not useful for us.
The flashing approach is just to get rid of *any* panel programming so that we never have to send the 0xff 12 83 01 sequence. But if we want to be able to program the panel, it might not be the solution.
The question is: Is that programming sequence needed for ALL settings or just for the basic ones?
Changing something like the bit depth, etc. can usually be done on-the-fly, does that need a full reprogramming as well?
Basically I asked BOE if we can have the panel boot up as if the 0xff 12 83 01 sequence were already sent.
Let’s wait for their answer.
What I have done: a) connect the (programmed) panel w/o SSD to the OMAP b) power up, remove reset, enable DCS c) try to read “ORISE2” registers -> failed d) enabled CMD2_ENA1 through the censored command, and I could read some ORISE2 register
The idea is to set the CMD2_ENA1 and CMD2_ENA2 registers as “enabled” through OTP so that we never need to send this problematic sequence. But it appears that it is not.
Unfortunately the data sheet is a little contradicting itself. It is not clear if this register can be read back. And what the “default” value from OTP means.
Maybe something we can ask BOE again.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- 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