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...
1. Redesign the case 2. Take care once again of the touchscreen 3. 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...
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. Can this be changed with flashing as well? Maybe we could change it to something different. Or is that a non-configurable option of the Orise?
* Would it be possible to program the Panel through the SSD? Or does the programming sequence also start with 0xff? If it's possible, how complicated would it be to make the Panel flashable from Pyras hardware?
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