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)!