Am 21.03.2019 um 07:05 schrieb H. Nikolaus Schaller hns@goldelico.com:
HI,
Am 20.03.2019 um 16:31 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:30 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:19 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 19 Mar 2019 13:30:17 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
>> * GTA04A4: backlight ok, display shows white pixels only > > hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok > 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Ah, I didn't read precisely: "black screen". I get this as well if I eliminate most Letux patch sets.
This means that one or two hacks are not yet upstream...
well, echo 0 >/sys/class/backlight/backlight/bl_power resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1
I think we are talking about different problems.
Looks so...
My main symptom is that I get a /dev/fb0, X server process is running, backlight is on, but the screen is completely white. And xset dpms force on/off can turn backlight on&off. But still only white pixels.
I have now checked and the symptoms are two facets of the same problem.
When doing my git bisect of linus/master plus adding only 4 of our letux patches, I get a black display in the error case which goes completely white when echoing to bp_power.
I never had the backlight staying black but display working.
But there remains some difference by adding the full letux patch set. I.e. some piece of code does have the same side effect as echo 0 >/sys/class/backlight/backlight/bl_power
So we could probably check
cat /sys/class/backlight/backlight/bl_power
after boot to automate the bisect (1 = bad, 0 = good).
I guess the problem is either the SPI interface to the panel or the pixel clock/pixel data.
I am currently running a bisect to find out more.
First result:
Here is a new result after repeating with git bisect start '--no-checkout' '--' 'arch/arm' 'include/' 'drivers/'
f90d64483ebd394958841f67f8794ab203b319a7 is the first bad commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
67e79a6dc2664a3ef85113440e60f7aaca3c7815 is the first bad commit
i.e.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
But what does this have to do with the GTA04 display and backlight power???
Same question for the new result... This time it is a different merge. In both cases a merge of subsystem updates and not a single patch. Strange.
I fear a side-effect of an array out of bounds write like we did have a while ago.
Or I did make a mistake in reporting good/bad to git bisect. Maybe I should repeat.
Note this is using mainline linux (bisected) + letux/compile-fixes + letux/arm_defconfig + letux/Letux + letux/ubi-fs and nothing else. So it does not include many of the Letux hacks.
So at the moment I have no good idea how to debug it. Maybe we should wait until v5.1-rc2 is out. Someone else might have a similar issue or a late fix is provided that is missing in v5.1-rc1.
Some more observations (in failed state):
a) panel driver is loaded
root@letux:~# lsmod|fgrep td0 panel_tpo_td028ttec1 16384 3 omapdss_base 16384 5 connector_analog_tv,encoder_opa362,panel_tpo_td028ttec1,omapdrm,omapdss root@letux:~#
b) video cards are initialized
root@letux:~# ls -l /sys/devices/platform/omapdrm.0/drm/card0/card0-* /sys/devices/platform/omapdrm.0/drm/card0/card0-DPI-1: total 0 lrwxrwxrwx 1 root root 0 Mar 21 07:11 device -> ../../card0 -r--r--r-- 1 root root 4096 Mar 21 07:11 dpms -r--r--r-- 1 root root 0 Mar 21 07:11 edid -r--r--r-- 1 root root 4096 Mar 21 07:11 enabled -r--r--r-- 1 root root 4096 Mar 21 07:11 modes drwxr-xr-x 2 root root 0 Mar 21 07:06 power -rw-r--r-- 1 root root 4096 Mar 21 07:11 status lrwxrwxrwx 1 root root 0 Mar 21 07:11 subsystem -> ../../../../../../class/drm -rw-r--r-- 1 root root 4096 Mar 21 06:28 uevent
/sys/devices/platform/omapdrm.0/drm/card0/card0-SVIDEO-1: total 0 lrwxrwxrwx 1 root root 0 Mar 21 07:11 device -> ../../card0 -r--r--r-- 1 root root 4096 Mar 21 07:11 dpms -r--r--r-- 1 root root 0 Mar 21 07:11 edid -r--r--r-- 1 root root 4096 Mar 21 07:11 enabled -r--r--r-- 1 root root 4096 Mar 21 07:11 modes drwxr-xr-x 2 root root 0 Mar 21 07:06 power -rw-r--r-- 1 root root 4096 Mar 21 07:11 status lrwxrwxrwx 1 root root 0 Mar 21 07:11 subsystem -> ../../../../../../class/drm -rw-r--r-- 1 root root 4096 Mar 21 06:28 uevent root@letux:~#
c) the panel seems to be programmed through SPI
root@letux:/sys/bus/spi/drivers/panel-tpo-td028ttec1/spi4.0# for i in statistics/*; do echo $i $(cat $i); done statistics/bytes 202 statistics/bytes_rx 0 statistics/bytes_tx 202 statistics/errors 0 statistics/messages 48 statistics/spi_async 0 statistics/spi_sync 48 statistics/spi_sync_immediate 48 statistics/timedout 0 statistics/transfer_bytes_histo_0-1 0 statistics/transfer_bytes_histo_1024-2047 0 statistics/transfer_bytes_histo_128-255 0 statistics/transfer_bytes_histo_16-31 0 statistics/transfer_bytes_histo_16384-32767 0 statistics/transfer_bytes_histo_2-3 7 statistics/transfer_bytes_histo_2048-4095 0 statistics/transfer_bytes_histo_256-511 0 statistics/transfer_bytes_histo_32-63 0 statistics/transfer_bytes_histo_32768-65535 0 statistics/transfer_bytes_histo_4-7 41 statistics/transfer_bytes_histo_4096-8191 0 statistics/transfer_bytes_histo_512-1023 0 statistics/transfer_bytes_histo_64-127 0 statistics/transfer_bytes_histo_65536+ 0 statistics/transfer_bytes_histo_8-15 0 statistics/transfer_bytes_histo_8192-16383 0 statistics/transfers 48 statistics/transfers_split_maxsize 0 root@letux:/sys/bus/spi/drivers/panel-tpo-td028ttec1/spi4.0#
BR, Nikolaus