HI, I have been working and fixing many details for the Pyra display system in the last days.
Since I think we can distribute the sample boards soon to run on the EVM, I thought it is good to write down how this all works (because there is no information elsewhere than in my memory).
The current status (tip of http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/4.0-rc5):
* the default device tree (omap5-pyra.dts) is configured to use the panel-mipi-debug driver * there are scripts in the GTA04/root directory to program the panel and the debug driver through shell scripts * all this goes through the “dcs” file in the /sys - but the script creates a symlink in /root for easier command line tests * the syntax is provided by ‘cat dcs’ * it can read/write DCS commands and generic read/write packets (e.g. write 2 bytes and read 4) * there are also commands to control power/reset GPIOs and start the DSI system and start/stop the video stream * the start command allows to change some timing parameters on the OMAP side (e.g. horiz or vert resolution, pixelclock, lpclock) * mainly you just run the scripts form a shell: - ./ssd2858-p -s - tries to program the ssd with pass-through, enable the BOE panel, and start the video stream - ./ssd2858 -r -p -s - tries to program for rotation, enable the BOE panel, and start the video stream - ./boe-wl667 - programs the BOE panel (if connected with the display board without ssd2858) * all this is *not* run automatically during boot and must be done through the command line * there is a ./panelselect script that overwrites the device tree so that a “real” panel driver starts during boot (and there is no need for these scripts) * currently, this only works for the BOE panel without ssd2858 * mainly, this BOE driver contains the command list of the BOE script and sends it during setup
The real ssd2858 kernel driver will need quite a lot of work to make it universal (and independent of the BOE panel): * DT is already prepared to insert the ssd driver as a pipeline element between OMAP5 and BOE panel - so this should work (see omap5-pyra+ssd+boe.dts) * the driver has two ports: an in and a out port (OMAP has only an out port and a panel only an in port) * what it should do (but is far from doing yet): - ask the panel to initialize - forward DCS commands from the panel driver through the SSD (this code should almost work) - ask the panel (or store what the panel asks it through reverse port) for timing and parameters - some of these parameters must be forwarded to the OMAP DSI system, some must be recalculated - others (like horiz and vert pixels, front porch, lp clock frequency etc.) must be programmed into the ssd so that the MIPITX of the ssd is doing what the panel expects - and there should be some user-interface to control rotation - I don’t know if it can be done dynamically since this would require to reprogram the OMAP DSI port with different xres and yres - but the minimum should be a DT setting for the rotation (left/right/none) so that a specific combination of omap, ssd and panel can be made work
Now the most important thing about the ssd setup status:
it is showing something on the BOE panel :) But no picture related to frame buffer contents :(
Here are two photos:
What is obviously not yet correct are all the register settings of the ssd2858. I.e. my shell script is not sending the right bit combinations to the dcs file…
I have tried to measure the signals with the Oscilloscope (you can see the tiny wires :) and there are still some discrepancies between register descriptions in the data sheet, the ssd2858 clock diagram and what I really see.
For example I did set the LP clock divider as I did calculate it from my understanding - but it was too fast for the panel. I had to increase the divisor factor. But this would indicate a wrong byte clock setting - that is not compatible to the other divider settings but would indicate that the OMAP5 byte clock is used - which think I did not set (although it is possible).
The main issue appears to program all the multipliers and dividers in the chip correctly to get proper MIPI signal frequencies.
I have prepared a “cookbook” for these settings that describes all decisions and calculations in a logical sequence starting with what the panel wants to see, but it is still wrong. Maybe I should fix it and sell to Solomon because that is the missing manual they should be able to provide to their customers :)
So there will be more questions to Solomon next week.
In summary, we are almost done for demonstrating the ssd chip. But as you know “almost” might mean the most challenging task is still ahead :)
But making a good kernel driver out of my bring-up hacks is still some work to be done after that. This is something where the other kernel developers on this list could take over, as soon as the principles are understood by making a working demo. And the hardware is verified to be not a blocking point (I would have to fix that first or we loose a lot of time sending boards back for rework). Please note that the strange colored signals could still be a hardware bug on the interface connector requiring to swap two wires.
If someone wants to go through the panel driver code and the shell scripts, please ask what you don’t understand. In my view it is important to do this know-how-transfer / distribution in the next weeks.
BR and have nice holiday(s), Nikolaus