* Tony Lindgren <tony@xxxxxxxxxxx> [170413 07:59]:
> * Peter Ujfalusi <peter.ujfalusi@xxxxxx> [170413 06:49]:
> > On 2017-04-13 10:37, Tomi Valkeinen wrote:
> > > On 12/04/17 21:17, Tony Lindgren wrote:
> > > > 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.
>
> Adding the aliases fixes the /sys/class/graphics/fb0 issue in next
> as suggested by Tomi.
Oops, sorry that does not help. I also had revert of Peter's patch
applied. It also seems that starting HDMI on panda fails without
reverting Peter's patch.
And I'm also seeing random oopses on panda with Linux next after
restarting X 2 - 5 times.. But so far no luck trying to bisect
that down based on two attempts.
Regards,
Tony
--
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
