Am 01.10.2015 um 16:33 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 01.10.2015 um 08:39 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 29/09/15 17:10, Dr. H. Nikolaus Schaller wrote:
Hi, I have now an omapdrm/X11 driver configured on Debian Jessie 8.2.
LCD works fine :)
There is only one small glitch during X11 startup (besides the „atomic“ kernel warnings):
(EE) BUG: triggered 'if (minval > maxval && mode == 1)' (EE) BUG: ../../Xi/exevents.c:2087 in InitValuatorAxisStruct() (EE) (EE) Backtrace: (EE)
I don't see that on my X versions. I've attached my X log for reference.
Well, I think I (or someone else) can debug later since it is completely X related and neither kernel nor driver.
Oh, one thing: I do use the HEAD of xf86-video-omap, not the latest released version (0.4.3). There are a few patches on top.
Well, I have simply installed the Debian Jessie 8.2 package. Haven't checked which source version they use.
What should I try next? Compile the kernel with no LCD and check if HDMI only works?
You can try that,
I have now tried but it does not appear to make any difference (unless I did something wrong). Are the display aliases used and significant in omapdrm mode? Or are they ignored?
but also I still recommend getting some kernel modesetting test tool (modetest or something else). Testing with X is fine, but there are quite a few moving parts there. Having a simple KMS test is much better way to verify that the drivers/hardware is working.
Have compiled modetest on the omap5 and it works.
And now - I do not exactly know what I have done differently - HDMI works.
In good resolution (1280x800) independently of the LCD resolution.
Modetest is nice... And debugfs for the hpd gpios as well:
root@gta04:~# cat /sys/kernel/debug/gpio | fgrep hdmi gpio-193 (hdmi_hpd ) in hi gpio-464 (hdmi_ct_cp_hpd ) out hi gpio-465 (hdmi_ls_oe ) out lo gpio-496 (modem_vbus_hdmi_powe) out hi root@gta04:~# xrandr Screen 0: minimum 320 x 200, current 720 x 1280, maximum 2048 x 2048 None-1 connected 720x1280+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 720x1280 60.00*+ HDMI-1 connected (normal left inverted right x axis y axis) 1280x800 59.81 + 119.91 1920x1080 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98 1280x1024 75.02 60.02 1440x900 59.90 1366x768 59.79 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 119.99 75.08 70.07 60.00 800x600 119.97 72.19 75.00 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 119.99 75.00 72.81 66.67 60.00 59.94 root@gta04:~#
It appears that they share a common big frame buffer (localhost:0.0) and effectively they are just two windows that can be moved around showing the same or different parts of the big "Screen".
It now works on both, the OMAP5 uevm and our own hardware. So my main target - to prove that the HDMI hardware is working as expected - is reached.
But the "atomic complete timeout" is a strange symptom. It only appears in DRM mode (even w/o X11) and I just have changed this:
diff --git a/arch/arm/configs/letux_defconfig b/arch/arm/configs/letux_defconfig index 3fa84ef..3d2cd83 100644 --- a/arch/arm/configs/letux_defconfig +++ b/arch/arm/configs/letux_defconfig @@ -2613,7 +2613,8 @@ CONFIG_DRM_I2C_NXP_TDA998X=m # CONFIG_DRM_EXYNOS is not set # CONFIG_DRM_UDL is not set # CONFIG_DRM_ARMADA is not set -# CONFIG_DRM_OMAP is not set +CONFIG_DRM_OMAP=m +CONFIG_DRM_OMAP_NUM_CRTCS=2 CONFIG_DRM_TILCDC=m CONFIG_DRM_TILCDC_SLAVE_COMPAT=y # CONFIG_DRM_STI is not set @@ -2626,15 +2627,15 @@ CONFIG_FIRMWARE_EDID=y CONFIG_FB_CMDLINE=y # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set -CONFIG_FB_CFB_FILLRECT=y -CONFIG_FB_CFB_COPYAREA=y -CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_FILLRECT is not set +# CONFIG_FB_CFB_COPYAREA is not set +# CONFIG_FB_CFB_IMAGEBLIT is not set # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set -# CONFIG_FB_SYS_FOPS is not set +CONFIG_FB_SYS_FOPS=m # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set @@ -2670,9 +2671,7 @@ CONFIG_OMAP2_DSS_SDI=y CONFIG_OMAP2_DSS_DSI=y CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET=y -CONFIG_FB_OMAP2=y -CONFIG_FB_OMAP2_DEBUG_SUPPORT=y -CONFIG_FB_OMAP2_NUM_FBS=3 +# CONFIG_FB_OMAP2 is not set
# # OMAP Display Device Drivers (new device model)
What I have found is that the "atomic complete" disappears if I delete the panel (!) driver. And comes back if I restore. Deleting the hdmi driver does not make it disappear - so it is not a multi-monitor issue.
It is an issue of the panel driver if run in DRM mode.
Do you see anything critical in our panel driver (which works perfectly in omapfb mode):
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/video/fbdev/om...
After thinking about this in a background task, there maybe an important difference to other panel drivers (I don't see this issue on the OMAP3 with SPI/DPI panel).
We don't call in->ops.dsi->set_config() and in->ops.dsi->enable_hs() in the probe function.
They are called much later by a shell script (through a /sys interface) so that we are able to configure / tweak the panel timings to different panel setups.
Is there an implicit assumption what must be called in the panel driver's probe function?
And touch screen is unuseable - looks as if something gets flooded by touch events:
[ 367.402778] omap_crtc_error_irq: 140957 callbacks suppressed [ 367.408760] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.415975] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.435473] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.442665] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000 [ 367.468852] [drm:omap_irq_handler [omapdrm]] *ERROR* tv: errors: 00008000
The effect is screen flicker and the X mouse cursor lagging 1-2 seconds behind.
Completely disappears in OMAPFB mode.
BR, Nikolaus Schaller
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel