Am 01.03.2015 um 18:17 schrieb Michael Mrozek mrozek@openpandora.org:
Am Sun, 1 Mar 2015 15:18:35 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Well, we can switch to the Success panel, a Linux driver exists and it's cheaper.
However, we'd need to...
0. make it work on our setup.
- Redesign the case
- Take care once again of the touchscreen
- Have the risk that the panel production is not consistent (as
Success simply took over the production line, they don't know what they're doing). This was an issue with the Pandora: Each batch had different colors, gamma and even touchscreen...
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.
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.
Can this be changed with flashing as well?
No.
Maybe we could change it to something different. Or is that a non-configurable option of the Orise?
I think we already clarified.
Neither with ORISE nor with Solomon it is possible to change it (or they would have to redesign their chips). They just happened to use the same “escape” sequence code.
- 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.
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.
Or does the programming sequence also start with 0xff?
Yes. See above.
If it's possible, how complicated would it be to make the Panel flashable from Pyras hardware?
Quite complicated. You need a hardware bypass for MIPI signals (~400 MHz). This is not that easy and costs additional money.
And, if we have this bypass, we do not even have to flash the panel, because we can reprogram it on every boot.
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.
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