Hi,
it seems there's no driver yet for Linux, but hopefully, it shouldn't be too hard writing one (as it basically only needs to send MIPI commands).
Solomon Systech has created an Excel-Sheet for us which has the commands included to initialize the chip and set it to 1280x720 rotated. It is attached.
I guess the best way is to create a Display driver, so that Linux thinks the chip is a standard monitor supporting multiple resolutions.
It would be great if we include many standard resolutions (like 800x480, 800x600, 640x480, 1024x600, etc.) which will be reported as standard modes to Linux.
It should also include resolutions without rotation (720x1280, 480x800, etc.) in case a developer wants to disable the rotation (i.e. for OpenGLES games, as it can handle rotation without compression or portrait games).
Stuff like color correction, etc. (the chip can do that as well) can be implemented at a later stage.
Does that make sense in your opinion?
Of course, the most important thing at first is to get a very preliminary driver working, so we can test both displays we'll get within the next few weeks (the BOE and Success one).
Which brings up the question: How do we handle multiple displays?
Does it make sense coding a generic driver for the Solomon Chip and add displays via external config files, or should we include the various display configuration (and recognization routines) inside the driver directly?
Does anyone have time to code the driver?
Thanks in advance :)
On 08/04/14 05:10, Michael Mrozek wrote:
Which brings up the question: How do we handle multiple displays?
Does it make sense coding a generic driver for the Solomon Chip and add displays via external config files, or should we include the various display configuration (and recognization routines) inside the driver directly?
There should be a dedicated driver for the chip and each of the panels. The selection of the chip and panel to be used is done in the DT data passed to the kernel.
Tomi
Am 08.04.2014 um 04:10 schrieb Michael Mrozek:
Hi,
it seems there's no driver yet for Linux, but hopefully, it shouldn't be too hard writing one (as it basically only needs to send MIPI commands).
Solomon Systech has created an Excel-Sheet for us which has the commands included to initialize the chip and set it to 1280x720 rotated. It is attached.
I guess the best way is to create a Display driver, so that Linux thinks the chip is a standard monitor supporting multiple resolutions.
It would be great if we include many standard resolutions (like 800x480, 800x600, 640x480, 1024x600, etc.) which will be reported as standard modes to Linux.
It should also include resolutions without rotation (720x1280, 480x800, etc.) in case a developer wants to disable the rotation (i.e. for OpenGLES games, as it can handle rotation without compression or portrait games).
Stuff like color correction, etc. (the chip can do that as well) can be implemented at a later stage.
Does that make sense in your opinion?
I would start with full screen rotation (only).
Then it should be copy&paste plus some adjustments from the Renesas driver. Because for DSS/DPI it looks like a panel.
Scaling is then something we can do after choosing a panel.
Generally I am not sure if the LCD DSS drivers are prepared for panels that allow to change the resolution on the fly.
Of course, the most important thing at first is to get a very preliminary driver working, so we can test both displays we'll get within the next few weeks (the BOE and Success one).
One issue is that it needs a table/driver wiht commands to initialize the real panel.
Which brings up the question: How do we handle multiple displays?
An #ifdef? Or it might be possible to query the panels for their manufacturer ID and choose between two tables of initialization commands.
Does it make sense coding a generic driver for the Solomon Chip
yes.
and add displays via external config files, or should we include the various display configuration (and recognization routines) inside the driver directly?
It should be more universally useable if we have a chain of drivers. That is how the DSS is modeled e.g. for the BeagleBoard DVI driver chip plus external connector. So this chip has a driver and the connector/resp. really connected display.
Does anyone have time to code the driver?
Most likely I have to do it anyways to hack together a first working driver to be able to bring up the hardware.
Thanks in advance :)
-- 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 <SSD2858_Rotate_20140407.xlsx>_______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 08/04/14 12:27, Dr. H. Nikolaus Schaller wrote:
Generally I am not sure if the LCD DSS drivers are prepared for panels that allow to change the resolution on the fly.
The DSS doesn't care much, it just gets told which resolution and timings to use.
I think the interesting part here is how to tell DRM that there are multiple modes. Traditionally DRM reads edid via i2c, and gets the modes from there. Pyra won't have i2c nor EDID.
I think a simple option to get going is to create a fake EDID, and return that via the read_edid() call to the panel drivers.
Of course, the most important thing at first is to get a very preliminary driver working, so we can test both displays we'll get within the next few weeks (the BOE and Success one).
One issue is that it needs a table/driver wiht commands to initialize the real panel.
No, that should be done in the panel driver. The chip driver just implements an API that allows sending DSI packets from the chip to the panel.
Which brings up the question: How do we handle multiple displays?
An #ifdef? Or it might be possible to query the panels for their manufacturer ID and choose between two tables of initialization commands.
It should be done by having different DT data for different panels. That said, the DT data can be created/modified in u-boot, so it's an option to make u-boot detect the panel, and then pass proper DT data to the kernel.
Tomi
On 08/04/14 05:10, Michael Mrozek wrote:
It would be great if we include many standard resolutions (like 800x480, 800x600, 640x480, 1024x600, etc.) which will be reported as standard modes to Linux.
It should also include resolutions without rotation (720x1280, 480x800, etc.) in case a developer wants to disable the rotation (i.e. for OpenGLES games, as it can handle rotation without compression or portrait games).
My gut feeling is that hiding the rotation that way is not a good idea. However, it's not clear to me how exposing the rotation via drm should be done, so your idea is definitely an option, especially for the first implementation, as rotation that way is probably simple to implement.
Tomi
On Tue, Apr 8, 2014 at 5:10 AM, Michael Mrozek EvilDragon@openpandora.org wrote:
Hi,
it seems there's no driver yet for Linux, but hopefully, it shouldn't be too hard writing one (as it basically only needs to send MIPI commands).
Solomon Systech has created an Excel-Sheet for us which has the commands included to initialize the chip and set it to 1280x720 rotated. It is attached.
I guess the best way is to create a Display driver, so that Linux thinks the chip is a standard monitor supporting multiple resolutions.
It would be great if we include many standard resolutions (like 800x480, 800x600, 640x480, 1024x600, etc.) which will be reported as standard modes to Linux.
We'll need similar tables from Solomon for each scaled mode we want to support, also scaler registers settings and coefficient tables. Or some guide how to calculate those values, even though the datasheet explains how the hardware works, it's not obvious how to generate filter tables without knowing FIR filter theory.
Am Tue, 8 Apr 2014 14:25:17 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
I've sent a general Excel-Document a while ago, can't remember if it was included there already.
Otherwise, doesn't the datasheet have that included? If not, I'll simply ask them :)
On Tue, Apr 8, 2014 at 5:10 AM, Michael Mrozek EvilDragon@openpandora.org wrote:
Hi,
it seems there's no driver yet for Linux, but hopefully, it shouldn't be too hard writing one (as it basically only needs to send MIPI commands).
Solomon Systech has created an Excel-Sheet for us which has the commands included to initialize the chip and set it to 1280x720 rotated. It is attached.
I guess the best way is to create a Display driver, so that Linux thinks the chip is a standard monitor supporting multiple resolutions.
It would be great if we include many standard resolutions (like 800x480, 800x600, 640x480, 1024x600, etc.) which will be reported as standard modes to Linux.
We'll need similar tables from Solomon for each scaled mode we want to support, also scaler registers settings and coefficient tables. Or some guide how to calculate those values, even though the datasheet explains how the hardware works, it's not obvious how to generate filter tables without knowing FIR filter theory.