On 2012-11-23 17:20, Steve Sakoman wrote: > On Fri, Nov 23, 2012 at 12:46 AM, Tomi Valkeinen <tomi.valkei...@ti.com> > wrote: > > >> Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you >> put a printk at dss/apply.c:dss_olv_set_info, and print ovl->id and >> info->paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at >> the point where it sets info.paddr, as I think that's the only place >> where omapfb sets paddr. > > OK, did that and here is what I get when starting up gdm, prior to > that all is normal > > root@omap3-multi:~# systemctl start gdm.service > Starting Gnome Display Manager... > Started Gnome Display Manager [ OK > ] > root@omap3-multi:~# [ 83.475128] omapfb_setup_plane entry > [ 83.479492] setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 > [ 83.485809] omapfb_setup_overlay: setting info.paddr = 9f400000 > [ 83.492431] dss_ovl_set_info entry > [ 83.496307] ovl->id = 0 > [ 83.499267] info->paddr = 9f400000 > [ 83.503601] omapfb_setup_plane: return success > [ 83.508697] omapfb_setup_plane entry > [ 83.513153] dss_ovl_set_info entry > [ 83.516723] ovl->id = 2 > [ 83.520111] info->paddr = 0 > [ 83.523406] omapdss OVERLAY error: check_overlay: paddr cannot be 0 > [ 83.530426] omapfb_setup_plane: !pi->enabled & ovl->set_overlay_info > [ 83.537414] dss_ovl_set_info entry > [ 83.540985] ovl->id = 2 > [ 83.544250] info->paddr = 0 > [ 83.547546] omapdss OVERLAY error: check_overlay: paddr cannot be 0 > > <repeats as X dies and restarts> > >> I don't know what's going on there, why the paddr is suddenly zero. >> Looking at the log from Enric, SETUP_PLANE works fine just fine, and >> then, for no reason, next SETUP_PLANE fails, and the log doesn't show >> anything much happening between. >> >> However, I think omapdss may have been more permissive in the past, >> allowing paddr 0 if the overlay is disabled. I could add that back, but >> I'd rather first understand what's happening here. > > From the above it seems that the first SETUP_PLANE is for ovl->id = 0 > and then those that fail are for ovl->id =2. > > No idea what is going on in user space, but maybe this will mean > something to you :-)
Ok. So X is configuring video2 overlay for some reason. XVideo, perhaps?
Anyway, I guess it's a valid thing to configure the overlay with
paddr == 0 when the overlay is disabled. In fact, paddr == 0 check
is in any case quite limited, as if the board's physical memory
doesn't contain the given paddr, the DSS HW will fail just as it
would for paddr 0. So the paddr == 0 check is more of a sanity check
than a comprehensive test.
Can you try the following patch:
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index 45f4994..e271e28 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -130,11 +130,6 @@ void dss_uninit_overlays(struct platform_device *pdev)
int dss_ovl_simple_check(struct omap_overlay *ovl,
const struct omap_overlay_info *info)
{
- if (info->paddr == 0) {
- DSSERR("check_overlay: paddr cannot be 0\n");
- return -EINVAL;
- }
-
if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) {
if (info->out_width != 0 && info->width != info->out_width) {
DSSERR("check_overlay: overlay %d doesn't support "
Tomi
signature.asc
Description: OpenPGP digital signature
