Hi, just to let you know (any i the hope that somebody has a good comment).
It is still not working although all ssd2858 registers (except one status register) have the same value.
The only diffs I can find are:
91c91 < 608c: 00 00 03 c2 ---
608c: 00 00 03 ca
And allmost all DSI/DISPC registers I can read from debugfs have the same value.
The only diffs are:
40c40 < DISPC_LINE_STATUS 000000fa ---
DISPC_LINE_STATUS 000000d0
103,104c103,104 < DISPC_OVL_BA0(VID1) 7f77c000 < DISPC_OVL_BA1(VID1) 7f77c000 ---
DISPC_OVL_BA0(VID1) 7f6dc000 DISPC_OVL_BA1(VID1) 7f6dc000
Line status must be different because it is the line counter which depends on where the "electron beam" is when the register is read.
I don't exactly know which registers DISPC_OVL_BA0 are and what they do but, I have digged through the source code and found out that the reason is a different framebuffer base address in omap_plane_atomic_update(). So it is just a side-effect of loading the driver in a different sequence compared to others. And should not be the reason for our symptoms.
The symptoms are: * with mipi-debug driver and ssd2858 script it works in normal or rotation mode (this is how ED presents the Pyra to the public) * it does not work (although it did last week) in ssd test pattern output mode. * with ssd2858.ko it shows a b/w striped pattern (which does not depend on video input) - but the pattern rotates if the ssd2858 is instructed to do so
* it does also not work in ssd test pattern output mode * I can see with oscilloscope on the ssd MIPI input lanes that there is a video input from the OMAP which also depends on the X11 image (e.g. start/stop iceweasel adds/removes a window and changes the signals)
* in ssd test mode I can see that the pattern changes every second which is what I expect (it should loop slowly through rgb colors) * the output signals differ between mipi-debug + ssd script and ssd2858.ko - although the ssd registers have the same values
What is most interesting is that with the ssd2858.ko the video output is running a little faster - although this is not obviously instructed by input signals or different register settings.
I think we have to ask the manufacturer of the ssd2858 if the chip has hidden registers...
BR, Nikolaus
Hi,
On Tue, May 3, 2016 at 1:22 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
I don't exactly know which registers DISPC_OVL_BA0 are and what they do but, I have digged through the source code and found out that the reason is a different framebuffer base address
It's the RAM address from where to fetch the image. the memory is dynamically allocated on every boot, so it's normal for address to change on each boot.
in omap_plane_atomic_update(). So it is just a side-effect of loading the driver in a different sequence compared to others. And should not be the reason for our symptoms.
The symptoms are:
- with mipi-debug driver and ssd2858 script it works in normal or rotation
mode (this is how ED presents the Pyra to the public)
- it does not work (although it did last week) in ssd test pattern output
mode.
- with ssd2858.ko it shows a b/w striped pattern (which does not depend on
video input) - but the pattern rotates if the ssd2858 is instructed to do so
As we know the SSD is very picky and requires programming sequence to be perfect or it just won't work.
It might be register programming order, especially DCS commands, you could try making a trace log of each register and DCS write and see if the order matches the script.
Could also easily be a timing issue. With mipi-debug you get huge delays between every register write because the system has to switch between userspace/kernelspace on each register write, while the driver does it all a lot faster. You can add some usleeps() everywhere as a test and maybe isolate later where the delay is really needed (assuming that's the problem at all).
Gražvydas
Hi,
Am 03.05.2016 um 13:08 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
On Tue, May 3, 2016 at 1:22 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
I don't exactly know which registers DISPC_OVL_BA0 are and what they do but, I have digged through the source code and found out that the reason is a different framebuffer base address
It's the RAM address from where to fetch the image. the memory is dynamically allocated on every boot, so it's normal for address to change on each boot.
Yes, that is why I assume it can be ignored.
in omap_plane_atomic_update(). So it is just a side-effect of loading the driver in a different sequence compared to others. And should not be the reason for our symptoms.
The symptoms are:
- with mipi-debug driver and ssd2858 script it works in normal or rotation mode (this is how ED presents the Pyra to the public)
- it does not work (although it did last week) in ssd test pattern output mode.
- with ssd2858.ko it shows a b/w striped pattern (which does not depend on video input) - but the pattern rotates if the ssd2858 is instructed to do so
As we know the SSD is very picky and requires programming sequence to be perfect or it just won't work.
It might be register programming order, especially DCS commands, you could try making a trace log of each register and DCS write and see if the order matches the script.
I have done that as well and did not find any difference in sequence.
Could also easily be a timing issue. With mipi-debug you get huge delays between every register write because the system has to switch between userspace/kernelspace on each register write, while the driver does it all a lot faster. You can add some usleeps() everywhere as a test and maybe isolate later where the delay is really needed (assuming that's the problem at all).
That is what I am currently trying. I already had msleep(1) but it might need even more sleep... Next test will be with msleep(100) after each dcs command.
BR and thanks, Nikolaus
Hi notaz,
Am 03.05.2016 um 13:13 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 03.05.2016 um 13:08 schrieb Grazvydas Ignotas notasas@gmail.com:
Could also easily be a timing issue. With mipi-debug you get huge delays between every register write because the system has to switch between userspace/kernelspace on each register write, while the driver does it all a lot faster. You can add some usleeps() everywhere as a test and maybe isolate later where the delay is really needed (assuming that's the problem at all).
That is what I am currently trying. I already had msleep(1) but it might need even more sleep... Next test will be with msleep(100) after each dcs command.
Well. I have added msleep(100). And removed _nosync from all gen_write and dcs_write commands. Because I assume that it will then sync with something.
Result: no difference. Grey stripes pattern. Except that it takes longer to boot!
So it is not a simple programming speed issue.
And another test I have done:
I have added a NO_SSD config option for the ssd2858.ko which disables all programming of the ssd chip, but still forwards the commands and activities from the panel driver to the OMAP DSI driver. And I have tested with the display board where no ssd2858 is installed and the omap mipi output is directly fed into the panel.
This setup works (unrotated of course).
I.e. all tricks added to make the man-in-the-middle driver work. It is only the ssd2858 which does not behave as instructed.
Some more ideas I have to test: * the reset impulse to the ssd is too short * there is not enough delay between releasing reset and starting programming (this is definitively longer with the mipi-debug+script)
Neither does explain why I don't see a difference in the control registers... Unless some internal modules could have been improperly reset so that they can't handle the register values correctly.
BR, Nikolaus
Hi, I haven't done much today for this topic. Here some current status.
Am 03.05.2016 um 15:51 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi notaz,
Am 03.05.2016 um 13:13 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 03.05.2016 um 13:08 schrieb Grazvydas Ignotas notasas@gmail.com:
Could also easily be a timing issue. With mipi-debug you get huge delays between every register write because the system has to switch between userspace/kernelspace on each register write, while the driver does it all a lot faster. You can add some usleeps() everywhere as a test and maybe isolate later where the delay is really needed (assuming that's the problem at all).
That is what I am currently trying. I already had msleep(1) but it might need even more sleep... Next test will be with msleep(100) after each dcs command.
Well. I have added msleep(100). And removed _nosync from all gen_write and dcs_write commands. Because I assume that it will then sync with something.
Result: no difference. Grey stripes pattern. Except that it takes longer to boot!
So it is not a simple programming speed issue.
And another test I have done:
I have added a NO_SSD config option for the ssd2858.ko which disables all programming of the ssd chip, but still forwards the commands and activities from the panel driver to the OMAP DSI driver. And I have tested with the display board where no ssd2858 is installed and the omap mipi output is directly fed into the panel.
This setup works (unrotated of course).
I.e. all tricks added to make the man-in-the-middle driver work. It is only the ssd2858 which does not behave as instructed.
Some more ideas I have to test:
- the reset impulse to the ssd is too short
- there is not enough delay between releasing reset and starting programming (this is definitively longer with the mipi-debug+script)
I have extended these delays. Makes no difference.
What I have found is a small difference in the sequence of the ssd2858 reset and dsi_display_enable() but trying to make it the same has not yet made it working.
One difference I have overlooked came to my mind this afternoon: we see some "atomic complete timeout" reports with the mipi-debug+script when X11 starts (and I think once before).
So far, I was happy that they have disappeared with the ssd2858.ko.
But it may have to do something with that it works with script! I think I have to find out what the atomic complete timeout tries to tell us...
BR, Nikolaus
here an example of the atomic complete timeout:
[ 640.633697] omapdrm omapdrm.0: atomic complete timeout (pipe 1)! [ 640.640631] ------------[ cut here ]------------ [ 640.645550] WARNING: CPU: 1 PID: 2220 at drivers/gpu/drm/omapdrm/omap_crtc.c:385 omap_crtc_atomic_flush+0x20/0xa4 [omapdrm] [ 640.657744] Modules linked in: bluetooth autofs4 usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs ipv6 arc4 wl18xx wlcore mac80211 cfg80211 omapdrm drm_kms_helper panel_boe_w677l cfbfillrect snd_soc_omap_hdmi_audio syscopyarea cfbimgblt dwc3 sysfillrect sysimgblt fb_sys_fops cfbcopyarea drm encoder_solomon_ssd2858 encoder_tpd12s015 connector_hdmi snd_soc_omap_abe_twl6040 w2cbw003_bluetooth omapdss snd_soc_twl6040 wwan_on_off leds_gpio pwm_bl pwm_omap_dmtimer ehci_omap wlcore_sdio dwc3_omap snd_soc_ts3a225e tsc2007 leds_is31fl319x twl6040_vibra bq27xxx_battery_i2c bq2429x_charger gpio_twl6040 leds_tca6507 bq27xxx_battery ina2xx as5013 palmas_gpadc palmas_pwrbutton tca8418_keypad bmg160_i2c bma150 bmp085_i2c usb3503 bmp085 bmg160_core input_polldev bmp280 snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap snd_pcm_dmaengine [ 640.737177] CPU: 1 PID: 2220 Comm: Xorg Not tainted 4.6.0-rc5-letux+ #192 [ 640.744327] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 640.750685] [<c010e70c>] (unwind_backtrace) from [<c010af30>] (show_stack+0x10/0x14) [ 640.758849] [<c010af30>] (show_stack) from [<c03ff324>] (dump_stack+0x88/0xc0) [ 640.766462] [<c03ff324>] (dump_stack) from [<c013064c>] (__warn+0xc0/0xec) [ 640.773707] [<c013064c>] (__warn) from [<c0130694>] (warn_slowpath_null+0x1c/0x20) [ 640.781727] [<c0130694>] (warn_slowpath_null) from [<bf390f64>] (omap_crtc_atomic_flush+0x20/0xa4 [omapdrm]) [ 640.792310] [<bf390f64>] (omap_crtc_atomic_flush [omapdrm]) from [<bf3677a4>] (drm_atomic_helper_commit_planes+0x1b8/0x1f4 [drm_kms_helper]) [ 640.805729] [<bf3677a4>] (drm_atomic_helper_commit_planes [drm_kms_helper]) from [<bf38f7e8>] (omap_atomic_complete+0x38/0x104 [omapdrm]) [ 640.818821] [<bf38f7e8>] (omap_atomic_complete [omapdrm]) from [<bf38fa54>] (omap_atomic_commit+0x1a0/0x1d8 [omapdrm]) [ 640.830383] [<bf38fa54>] (omap_atomic_commit [omapdrm]) from [<bf2bd6b0>] (drm_atomic_commit+0x50/0x60 [drm]) [ 640.841162] [<bf2bd6b0>] (drm_atomic_commit [drm]) from [<bf3656dc>] (drm_atomic_helper_connector_dpms+0x100/0x154 [drm_kms_helper]) [ 640.854042] [<bf3656dc>] (drm_atomic_helper_connector_dpms [drm_kms_helper]) from [<bf2b312c>] (drm_mode_obj_set_property_ioctl+0x108/0x1ec [drm]) [ 640.868340] [<bf2b312c>] (drm_mode_obj_set_property_ioctl [drm]) from [<bf2b3240>] (drm_mode_connector_property_set_ioctl+0x30/0x3c [drm]) [ 640.881886] [<bf2b3240>] (drm_mode_connector_property_set_ioctl [drm]) from [<bf2a5464>] (drm_ioctl+0x254/0x3dc [drm]) [ 640.893378] [<bf2a5464>] (drm_ioctl [drm]) from [<c0264d28>] (vfs_ioctl+0x18/0x34) [ 640.901360] [<c0264d28>] (vfs_ioctl) from [<c026533c>] (do_vfs_ioctl+0x2fc/0x32c) [ 640.909249] [<c026533c>] (do_vfs_ioctl) from [<c02653bc>] (SyS_ioctl+0x50/0x6c) [ 640.916953] [<c02653bc>] (SyS_ioctl) from [<c0107120>] (ret_fast_syscall+0x0/0x1c) [ 640.926759] ---[ end trace c6b7a52e1b170b83 ]--- [ 641.173446] omapdrm omapdrm.0: atomic complete timeout (pipe 1)!