Re: omapdrm regressions on n900

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2017-04-13 10:37, Tomi Valkeinen wrote:
On 12/04/17 21:17, Tony Lindgren wrote:
Hi Peter & Tomi,

Looks like commit a09d2bc15035 ("drm/omap: Use omapdss_stack_is_ready()
to check that the display stack is up") causes a regression on n900
where /sys/class/graphics/fb0 no longer exists so fb0 can't be
unblanked. Reverting the commit above fixes the issue.

Hmm yes, looks like omapdss_register_display() is broken if there are no
aliases defined. Peter, can you have a look at it?

Hrm, not sure what is broken there:

if (dssdev->dev->of_node) {
	id = of_alias_get_id(dssdev->dev->of_node, "display");

	if (id < 0)
		id = disp_num_counter++;
} else {
	id = disp_num_counter++;
}

if there are no aliases, of_alias_get_id() would return -ENODEV (-19). In such case the code will fall back to number the displays in load order. Probably the issue is that the TV would be the first display in the list and since it is not connected the FB is not created for it. The aliases in the DT file should fix the ordering and most likely fix the problem as well.

Unfortunately I can not boot my n900 with mainline kernel no matter how hard I try (I can not load the kernel with flasher-3.5 nor with 0xFFFF), so I can not test it.

Tony, as a quick test, you could try adding display aliases to n900's
dts. I think something like this:

	aliases {
		display0 = &acx565akm;
		display1 = &tv;
	};

Interestingly, on my AM5 EVM board things work just fine, even if I
remove the aliases, and even if I see that the omapdss_register_display
does things badly. So possibly there's something else wrong too.

Then another issue I'm seeing is that current mainline and next
produce the following omap_crtc_error_irq errors:

tsc2005 spi1.0: GPIO lookup for consumer reset
tsc2005 spi1.0: using device tree for GPIO lookup
of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/ocp@68000000/spi@48098000/tsc2005@0[0]' - status (0)
input: TSC2005 touchscreen as /devices/platform/68000000.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input0
omapdss_dss 48050000.dss: 48050000.dss supply vdda_video not found, using dummy regulator
DSS: OMAP DSS rev 2.0
omapdss_dss 48050000.dss: bound 48050400.dispc (ops dispc_component_ops [omapdss])
omapdss_dss 48050000.dss: bound 48050c00.encoder (ops venc_component_ops [omapdss])
of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/ocp@68000000/spi@48098000/acx565akm@2[0]' - status (0)
acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected
omapdrm omapdrm.0: DMM not available, disable DMM support
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004022
Console: switching to colour frame buffer device 100x30
[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004020
[drm:omap_crtc_error_irq] *ERROR* lcd: errors: 00004000

That's sync lost, so some config is wrong... When did it work the last
time? v4.10?

And then one more issue.. Starting X on n900 seems to produce
two desktops on top half of the LCD that are both 1/4 of the
size of the LCD :)

That's with the sync lost errors? If you get sync losts, you've lost
already and you will see random things on the screen.

 Tomi


- Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux