Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Daniel Vetter]

On Wed, Aug 2, 2017 at 1:54 PM, Tomi Valkeinen  wrote:
> On 02/08/17 13:12, Daniel Vetter wrote:
>> On Mon, Jul 31, 2017 at 04:21:51PM +0300, Tomi Valkeinen wrote:
>>> On 30/06/17 15:36, Daniel Vetter wrote:
>>>
 I don't think registering before everything is loaded make sense. On the
 big desktop driver chips we have all the bridge/encoder/panel drivers
 built into the driver. arm-soc loves to make everything a separate module,
 but in the end if you decided to not compile half of the driver you need,
 then it's not going to work.
>>>
>>> I don't think that's quite the same. On the desktop you just have the
>>> video card, and it's easy to enable that single component. On an
>>> embedded device you have the SoC's display controller and then possibly
>>> multiple external encoders/panels on the board. Those external
>>> components have to be separate modules, they can't be part of the SoC
>>> driver. The desktop video card matches only to the SoC's display controller.
>>
>> Please take a look at the encoder drivers both nouveau and i915 have had
>> (for older hw). In neither of these cases did we register an incomplete
>> driver.
>>
 Imo the only thing we should support to be hotplugged in drm is stuff you
 can physically hotplug (like atm connectors). Everything else just
 complicates the code for no good reason at all.
>>>
>>> "unplugging" components would not give much, I think, but allowing
>>> adding new displays at runtime would be a very good thing.
>>
>> We do, just register another drm_device.
>
> But a drm_device is the display controller ("graphics card") side of the
> whole, isn't it? Well, that's not exactly true, it also contains the
> output side, like panel, but it's the display controller that defines
> how many drm_devices we have.

This was a reply to "Adding new displays at runtime". We support that,
by either hotplugging drm_device or drm_connector. Not anything else.
And there's not a real-world use-case as in "you can physically
hotplug it" to support more, at least for now. There's a design
problem in armsoc (you're not the only one who want to make this
work), but I really don't understand why it's a use-case we care
about.

>>> It's not only about mistakenly having the driver disabled in the kernel
>>> config, it could also be that some base driver failed to probe, which
>>> then makes an encoder or a panel to defer probing as it can't get the
>>> base resource. But HDMI or some other panel would work fine, but with
>>> current architecture can't be used.
>>>
>>> And if you really want to optimize, one a phone-type device you could
>>> have the LCD driver built-in, but HDMI drivers as modules, and only load
>>> the HDMI drivers if the user actually needs the HDMI.
>>
>> I don't see why we should support this as a valid use-case. E.g. if i915
>> fails to load a component (just because it's all in the same .ko doesn't
>> mean it's not multiple bits, same way you can have multiple drivers in the
>> same .ko), we also fail the overall driver bind. Really not seeing any
>> difference with arm-soc vs. desktop here.
>
> I admit I'm not that familiar with the desktop side, but I don't follow.
>
> From the user's perspective, why would his board's HDMI not work, if the
> embedded panel fails, or the kernel doesn't have the driver for the
> panel? As a user, at least I would very much like the HDMI to work even
> if the other display doesn't.
>
> If there's a clear error on the panel side, the DRM driver can handle
> that and just leave the panel away. I think the real problems are the
> deferred probing and loading as modules, as we don't know when, if ever,
> the panel is ok.
>
> At least for me there's a clear distinction between, say, i915 and, say,
> boards with OMAP DSS hardware:
>
> i915 is one whole component, and if parts of it don't load, it makes
> sense that i915 as a whole doesn't load. And the i915 driver knows and
> understand about everything that i915 contains. And i915 can be a single
> .ko, splitting it into smaller .kos probably doesn't give much benefit.
>
> On an OMAP board, we have DSS in the SoC, which contains a bunch of
> subcomponents. Everything I said above about i915 goes also for DSS
> driver. Then we have external encoders and panels. Those have to be
> separate drivers and modules, as there can be any number of those, used
> in any combination, on any platform.
>
> If I'm configuring the kernel for my OMAP board which has HDMI output
> and a panel, and I want to use the HDMI output, it makes sense that I
> enable DSS and whatever is needed on the HDMI path. It doesn't really
> make sense that I also need to enable panel-foobar.
>
> It's almost as if my board has a GPIO chip, and I would need to enable
> and successfully load all the drivers for the devices using the GPIO
> chip until any of the devices would work.
>
> Now, I don't think this is a big issue, and I don't think normal users
> would often 

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tomi Valkeinen]

On 02/08/17 13:12, Daniel Vetter wrote:
> On Mon, Jul 31, 2017 at 04:21:51PM +0300, Tomi Valkeinen wrote:
>> On 30/06/17 15:36, Daniel Vetter wrote:
>>
>>> I don't think registering before everything is loaded make sense. On the
>>> big desktop driver chips we have all the bridge/encoder/panel drivers
>>> built into the driver. arm-soc loves to make everything a separate module,
>>> but in the end if you decided to not compile half of the driver you need,
>>> then it's not going to work.
>>
>> I don't think that's quite the same. On the desktop you just have the
>> video card, and it's easy to enable that single component. On an
>> embedded device you have the SoC's display controller and then possibly
>> multiple external encoders/panels on the board. Those external
>> components have to be separate modules, they can't be part of the SoC
>> driver. The desktop video card matches only to the SoC's display controller.
> 
> Please take a look at the encoder drivers both nouveau and i915 have had
> (for older hw). In neither of these cases did we register an incomplete
> driver.
> 
>>> Imo the only thing we should support to be hotplugged in drm is stuff you
>>> can physically hotplug (like atm connectors). Everything else just
>>> complicates the code for no good reason at all.
>>
>> "unplugging" components would not give much, I think, but allowing
>> adding new displays at runtime would be a very good thing.
> 
> We do, just register another drm_device.

But a drm_device is the display controller ("graphics card") side of the
whole, isn't it? Well, that's not exactly true, it also contains the
output side, like panel, but it's the display controller that defines
how many drm_devices we have.

>> It's not only about mistakenly having the driver disabled in the kernel
>> config, it could also be that some base driver failed to probe, which
>> then makes an encoder or a panel to defer probing as it can't get the
>> base resource. But HDMI or some other panel would work fine, but with
>> current architecture can't be used.
>>
>> And if you really want to optimize, one a phone-type device you could
>> have the LCD driver built-in, but HDMI drivers as modules, and only load
>> the HDMI drivers if the user actually needs the HDMI.
> 
> I don't see why we should support this as a valid use-case. E.g. if i915
> fails to load a component (just because it's all in the same .ko doesn't
> mean it's not multiple bits, same way you can have multiple drivers in the
> same .ko), we also fail the overall driver bind. Really not seeing any
> difference with arm-soc vs. desktop here.

I admit I'm not that familiar with the desktop side, but I don't follow.

From the user's perspective, why would his board's HDMI not work, if the
embedded panel fails, or the kernel doesn't have the driver for the
panel? As a user, at least I would very much like the HDMI to work even
if the other display doesn't.

If there's a clear error on the panel side, the DRM driver can handle
that and just leave the panel away. I think the real problems are the
deferred probing and loading as modules, as we don't know when, if ever,
the panel is ok.

At least for me there's a clear distinction between, say, i915 and, say,
boards with OMAP DSS hardware:

i915 is one whole component, and if parts of it don't load, it makes
sense that i915 as a whole doesn't load. And the i915 driver knows and
understand about everything that i915 contains. And i915 can be a single
.ko, splitting it into smaller .kos probably doesn't give much benefit.

On an OMAP board, we have DSS in the SoC, which contains a bunch of
subcomponents. Everything I said above about i915 goes also for DSS
driver. Then we have external encoders and panels. Those have to be
separate drivers and modules, as there can be any number of those, used
in any combination, on any platform.

If I'm configuring the kernel for my OMAP board which has HDMI output
and a panel, and I want to use the HDMI output, it makes sense that I
enable DSS and whatever is needed on the HDMI path. It doesn't really
make sense that I also need to enable panel-foobar.

It's almost as if my board has a GPIO chip, and I would need to enable
and successfully load all the drivers for the devices using the GPIO
chip until any of the devices would work.

Now, I don't think this is a big issue, and I don't think normal users
would often encounter it, but it does feel confusing when you hit the
problem when debugging or doing new kernel configs.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Daniel Vetter]

On Mon, Jul 31, 2017 at 04:21:51PM +0300, Tomi Valkeinen wrote:
> On 30/06/17 15:36, Daniel Vetter wrote:
> 
> > I don't think registering before everything is loaded make sense. On the
> > big desktop driver chips we have all the bridge/encoder/panel drivers
> > built into the driver. arm-soc loves to make everything a separate module,
> > but in the end if you decided to not compile half of the driver you need,
> > then it's not going to work.
> 
> I don't think that's quite the same. On the desktop you just have the
> video card, and it's easy to enable that single component. On an
> embedded device you have the SoC's display controller and then possibly
> multiple external encoders/panels on the board. Those external
> components have to be separate modules, they can't be part of the SoC
> driver. The desktop video card matches only to the SoC's display controller.

Please take a look at the encoder drivers both nouveau and i915 have had
(for older hw). In neither of these cases did we register an incomplete
driver.

> > Imo the only thing we should support to be hotplugged in drm is stuff you
> > can physically hotplug (like atm connectors). Everything else just
> > complicates the code for no good reason at all.
> 
> "unplugging" components would not give much, I think, but allowing
> adding new displays at runtime would be a very good thing.

We do, just register another drm_device.

> It's not only about mistakenly having the driver disabled in the kernel
> config, it could also be that some base driver failed to probe, which
> then makes an encoder or a panel to defer probing as it can't get the
> base resource. But HDMI or some other panel would work fine, but with
> current architecture can't be used.
> 
> And if you really want to optimize, one a phone-type device you could
> have the LCD driver built-in, but HDMI drivers as modules, and only load
> the HDMI drivers if the user actually needs the HDMI.

I don't see why we should support this as a valid use-case. E.g. if i915
fails to load a component (just because it's all in the same .ko doesn't
mean it's not multiple bits, same way you can have multiple drivers in the
same .ko), we also fail the overall driver bind. Really not seeing any
difference with arm-soc vs. desktop here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tomi Valkeinen]

On 30/06/17 15:36, Daniel Vetter wrote:

> I don't think registering before everything is loaded make sense. On the
> big desktop driver chips we have all the bridge/encoder/panel drivers
> built into the driver. arm-soc loves to make everything a separate module,
> but in the end if you decided to not compile half of the driver you need,
> then it's not going to work.

I don't think that's quite the same. On the desktop you just have the
video card, and it's easy to enable that single component. On an
embedded device you have the SoC's display controller and then possibly
multiple external encoders/panels on the board. Those external
components have to be separate modules, they can't be part of the SoC
driver. The desktop video card matches only to the SoC's display controller.

> Imo the only thing we should support to be hotplugged in drm is stuff you
> can physically hotplug (like atm connectors). Everything else just
> complicates the code for no good reason at all.

"unplugging" components would not give much, I think, but allowing
adding new displays at runtime would be a very good thing.

It's not only about mistakenly having the driver disabled in the kernel
config, it could also be that some base driver failed to probe, which
then makes an encoder or a panel to defer probing as it can't get the
base resource. But HDMI or some other panel would work fine, but with
current architecture can't be used.

And if you really want to optimize, one a phone-type device you could
have the LCD driver built-in, but HDMI drivers as modules, and only load
the HDMI drivers if the user actually needs the HDMI.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tomi Valkeinen]

On 04/07/17 18:09, Pavel Machek wrote:
> Hi!
> 
>> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
>> check?
>
> It appears the reason was that I didn't have
> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
>
> I think that's wrong. I don't own an analog TV, so why should I enable
> such option to get device's built-in display working?

 Indeed. Unfortunately I don't have a solution for that.

 DRM doesn't support adding devices after probe. So at omapdrm probe time
 we have to decide which displays to use. In the dts file, n900 defines
 the lcd and analog tv. omapdrm sees those, and, of course, must wait
 until their respective drivers have probed. If you don't have the
 display driver enabled, it's never loaded and omapdrm never probes as it
 keeps waiting for those.
>>>
>>> Could you at least print some kind of message early in the boot ("omapdrm
>>> is waiting for drivers for display x and y")?
>>
>> That could be quite spammy. omapdrm will defer probe if the displays are
>> not present, and the deferred probing machinery will then cause a new
>> omapdrm probe later. That can happen a lot of times before the drivers
>> are there.
> 
> Well doing printk just once should not be a problem...?

I'm not sure if that would really help much... And you would practically
always see the print, even when everything works fine, which would be
useless and could raise false alarms.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [BISECTED,REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Clayton Craft]

Well, I tried that (attached), but it didn't work either. For some
reason the error worker seems to stop after the disable. Possibly the
irq flood keeps it from running, so maybe it should catch all the errors
(I see underflows too).

Sorry, but I can't use more time on this today, and I'm leaving for
vacation today. I hope Laurent can help during my absence.

We could try reverting the patch you mention, but I think it doesn't
cause the problem.

Did you have CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled earlier when
things worked? If you didn't, and the dts did not contain display
aliases, I think the omapdrm may have started without TV. So maybe the
TV side is the culprit, somehow (I couldn't find anything when I looked
at that side either).


Just curious if any progress has been made on this issue. It's still
happening with 4.13-rc1, and it doesn't look like any of the suspect
patches were reverted.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Pavel Machek]

Hi!

>  Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
>  check?
> >>>
> >>> It appears the reason was that I didn't have
> >>> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
> >>>
> >>> I think that's wrong. I don't own an analog TV, so why should I enable
> >>> such option to get device's built-in display working?
> >>
> >> Indeed. Unfortunately I don't have a solution for that.
> >>
> >> DRM doesn't support adding devices after probe. So at omapdrm probe time
> >> we have to decide which displays to use. In the dts file, n900 defines
> >> the lcd and analog tv. omapdrm sees those, and, of course, must wait
> >> until their respective drivers have probed. If you don't have the
> >> display driver enabled, it's never loaded and omapdrm never probes as it
> >> keeps waiting for those.
> > 
> > Could you at least print some kind of message early in the boot ("omapdrm
> > is waiting for drivers for display x and y")?
> 
> That could be quite spammy. omapdrm will defer probe if the displays are
> not present, and the deferred probing machinery will then cause a new
> omapdrm probe later. That can happen a lot of times before the drivers
> are there.

Well doing printk just once should not be a problem...?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Fri, Jun 30, 2017 at 11:47:55AM +0300, Tomi Valkeinen wrote:
> > So, I don't know... I guess I need to try to invent some horrible hacks
> > around the driver to somehow manage the omap3 problems. Perhaps
> > disabling/enabling the outputs when sync lost happens...
> 
> Well, I tried that (attached), but it didn't work either. For some
> reason the error worker seems to stop after the disable. Possibly the
> irq flood keeps it from running, so maybe it should catch all the errors
> (I see underflows too).
> 
> Sorry, but I can't use more time on this today, and I'm leaving for
> vacation today. I hope Laurent can help during my absence.
> 
> We could try reverting the patch you mention, but I think it doesn't
> cause the problem.

True, reverting the patch only allows me to use display without connector.
And apparently it just works by luck.

> Did you have CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled earlier when
> things worked?

No. I have never enabled it before, I didn't even know it was supported
by the mainline.

> If you didn't, and the dts did not contain display aliases, I think the
> omapdrm may have started without TV. So maybe the TV side is the culprit,
> somehow (I couldn't find anything when I looked at that side either).

Could be. 

Here is the summary from my testing:

0) v4.17-rc7 + connector disabled

==> nothing happens, omapdrm waits forever for connector driver

1) v4.17-rc7 + connector disabled +
   Revert "drm/omap: Use omapdss_stack_is_ready()"

==> LCD error flood, system unusable

2) v4.17-rc7 + connector disabled +
   Revert "drm/omap: Use omapdss_stack_is_ready()" +
   Apply "drm/omap: work-around for omap3 display enable"

==> display works!

3) v4.17-rc7 + connector enabled +
   Revert "drm/omap: Use omapdss_stack_is_ready()" +
   Apply "drm/omap: work-around for omap3 display enable"

==> LCD error flood, system unusable

4) v4.17-rc7 + connector enabled +
   Apply "drm/omap: work-around for omap3 display enable"

==> LCD error flood, system unusable

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Fri, Jun 30, 2017 at 09:41:35AM +0300, Tomi Valkeinen wrote:
> On 29/06/17 21:50, Aaro Koskinen wrote:
> > On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> >> On 15/06/17 01:11, Aaro Koskinen wrote:
> >>> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> >>> is no display.
> >>
> >> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> >> check?
> > 
> > It appears the reason was that I didn't have
> > CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
> > 
> > I think that's wrong. I don't own an analog TV, so why should I enable
> > such option to get device's built-in display working?
> 
> Indeed. Unfortunately I don't have a solution for that.
> 
> DRM doesn't support adding devices after probe. So at omapdrm probe time
> we have to decide which displays to use. In the dts file, n900 defines
> the lcd and analog tv. omapdrm sees those, and, of course, must wait
> until their respective drivers have probed. If you don't have the
> display driver enabled, it's never loaded and omapdrm never probes as it
> keeps waiting for those.

Could you at least print some kind of message early in the boot ("omapdrm
is waiting for drivers for display x and y")?

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tony Lindgren]

* Aaro Koskinen  [170629 11:50]:
> Is it just me or do other OMAP users fail to see omapdrm changes being
> posted to linux-omap for testing or review purposes?

Yeah Cc:ing linux-omap in addition to the drm list is a good idea. Hopefully
we get few more people to review changes that way.

What also should help preventing regressions is getting the changes into
Linux next early on during the -rc cycle. And switching the defconfigs to
use omapdrm instead of omapfb. Maybe we should do that right after v4.13-rc1
is tagged.

Cheers,

Tony
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Daniel Vetter]

On Fri, Jun 30, 2017 at 09:41:35AM +0300, Tomi Valkeinen wrote:
> On 29/06/17 21:50, Aaro Koskinen wrote:
> > Hi,
> > 
> > On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> >> On 15/06/17 01:11, Aaro Koskinen wrote:
> >>> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> >>> is no display.
> >>
> >> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> >> check?
> > 
> > It appears the reason was that I didn't have
> > CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
> > 
> > I think that's wrong. I don't own an analog TV, so why should I enable
> > such option to get device's built-in display working?
> 
> Indeed. Unfortunately I don't have a solution for that.
> 
> DRM doesn't support adding devices after probe. So at omapdrm probe time
> we have to decide which displays to use. In the dts file, n900 defines
> the lcd and analog tv. omapdrm sees those, and, of course, must wait
> until their respective drivers have probed. If you don't have the
> display driver enabled, it's never loaded and omapdrm never probes as it
> keeps waiting for those.
> 
> omapdrm could start when some of the drivers are missing, but then the
> question comes: when? omapdrm doesn't know if the driver will be probed
> at some later time, or maybe it is a module, loaded later by the userspace.
> 
> So, unless the DRM framework is modified to support adding displays
> after probe, I don't see a solution for this.
> 
> >> If that's the case then this is easier to debug.
> > 
> > Sure it's always easy... when users do all the testing and debugging.
> > 
> > Is it just me or do other OMAP users fail to see omapdrm changes being
> > posted to linux-omap for testing or review purposes?
> 
> I thought linux-omap was more for omap platform thingies. But sure, I
> can start cc'ing linux-omap for all omapdrm patches.
> 
> > And now I face another issue. When I boot v4.12-rc7 with
> > CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled and your "misc fixes"
> > patches on N900, I get the error flood again, and the device is unusable:
> 
> Yes, I think there's still something wrong. I haven't been able to find
> out what.
> 
> Somehow delays seem to help (like enabling debug prints), but I haven't
> been able to find out where exactly the delay is needed.
> 
> And I'd rather not revert the patch, because there's nothing wrong with
> that patch as such, and it fixes issues on all platforms.
> 
> So, I don't know... I guess I need to try to invent some horrible hacks
> around the driver to somehow manage the omap3 problems. Perhaps
> disabling/enabling the outputs when sync lost happens...

I don't think registering before everything is loaded make sense. On the
big desktop driver chips we have all the bridge/encoder/panel drivers
built into the driver. arm-soc loves to make everything a separate module,
but in the end if you decided to not compile half of the driver you need,
then it's not going to work.

Imo the only thing we should support to be hotplugged in drm is stuff you
can physically hotplug (like atm connectors). Everything else just
complicates the code for no good reason at all.

tldr; Wrong .config gives you a non-working driver, no surprises. And due
to the "default n" rule this can even look like a regression.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tomi Valkeinen]

On 30/06/17 11:58, Aaro Koskinen wrote:
> Hi,
> 
> On Fri, Jun 30, 2017 at 09:41:35AM +0300, Tomi Valkeinen wrote:
>> On 29/06/17 21:50, Aaro Koskinen wrote:
>>> On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
 On 15/06/17 01:11, Aaro Koskinen wrote:
> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> is no display.

 Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
 check?
>>>
>>> It appears the reason was that I didn't have
>>> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
>>>
>>> I think that's wrong. I don't own an analog TV, so why should I enable
>>> such option to get device's built-in display working?
>>
>> Indeed. Unfortunately I don't have a solution for that.
>>
>> DRM doesn't support adding devices after probe. So at omapdrm probe time
>> we have to decide which displays to use. In the dts file, n900 defines
>> the lcd and analog tv. omapdrm sees those, and, of course, must wait
>> until their respective drivers have probed. If you don't have the
>> display driver enabled, it's never loaded and omapdrm never probes as it
>> keeps waiting for those.
> 
> Could you at least print some kind of message early in the boot ("omapdrm
> is waiting for drivers for display x and y")?

That could be quite spammy. omapdrm will defer probe if the displays are
not present, and the deferred probing machinery will then cause a new
omapdrm probe later. That can happen a lot of times before the drivers
are there.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tomi Valkeinen]

On 30/06/17 09:41, Tomi Valkeinen wrote:

> So, I don't know... I guess I need to try to invent some horrible hacks
> around the driver to somehow manage the omap3 problems. Perhaps
> disabling/enabling the outputs when sync lost happens...

Well, I tried that (attached), but it didn't work either. For some
reason the error worker seems to stop after the disable. Possibly the
irq flood keeps it from running, so maybe it should catch all the errors
(I see underflows too).

Sorry, but I can't use more time on this today, and I'm leaving for
vacation today. I hope Laurent can help during my absence.

We could try reverting the patch you mention, but I think it doesn't
cause the problem.

Did you have CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled earlier when
things worked? If you didn't, and the dts did not contain display
aliases, I think the omapdrm may have started without TV. So maybe the
TV side is the culprit, somehow (I couldn't find anything when I looked
at that side either).

 Tomi
From c4ceb8934dbfa51bc966b927b17394c4b622712c Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen 
Date: Fri, 30 Jun 2017 11:39:53 +0300
Subject: [PATCH] drm/omap: hack error worker

---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 69 -
 1 file changed, 61 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c b/drivers/gpu/drm/omapdrm/omap_crtc.c
index dccd03726796..eb36b35f5eb8 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -36,12 +36,15 @@ struct omap_crtc {
 
 	struct videomode vm;
 
-	bool ignore_digit_sync_lost;
+	bool ignore_sync_lost;
 
 	bool enabled;
 	bool pending;
 	wait_queue_head_t pending_wait;
 	struct drm_pending_vblank_event *event;
+
+	struct work_struct error_work;
+	u32 error_channels;
 };
 
 /* -
@@ -157,7 +160,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, bool enable)
 		 * Digit output produces some sync lost interrupts during the
 		 * first frame when enabling, so we need to ignore those.
 		 */
-		omap_crtc->ignore_digit_sync_lost = true;
+		omap_crtc->ignore_sync_lost = true;
 	}
 
 	framedone_irq = priv->dispc_ops->mgr_get_framedone_irq(channel);
@@ -191,7 +194,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, bool enable)
 	}
 
 	if (omap_crtc->channel == OMAP_DSS_CHANNEL_DIGIT) {
-		omap_crtc->ignore_digit_sync_lost = false;
+		omap_crtc->ignore_sync_lost = false;
 		/* make sure the irq handler sees the value above */
 		mb();
 	}
@@ -263,17 +266,65 @@ static const struct dss_mgr_ops mgr_ops = {
  * Setup, Flush and Page Flip
  */
 
+static void omap_crtc_error_worker(struct work_struct *work)
+{
+	struct omap_crtc *omap_crtc = container_of(work, struct omap_crtc, error_work);
+	struct drm_crtc *crtc = _crtc->base;
+	struct drm_device *dev = omap_crtc->base.dev;
+	struct omap_drm_private *priv = dev->dev_private;
+
+	drm_modeset_lock(>mutex, NULL);
+
+	dev_warn(dev->dev, "sync lost on %s, enabling & disabling...\n",
+		omap_crtc->name);
+
+	priv->dispc_ops->mgr_enable(omap_crtc->channel, false);
+
+	msleep(50);
+	dev_warn(dev->dev, "sync lost enabling %s\n",
+			omap_crtc->name);
+
+	priv->dispc_ops->mgr_enable(omap_crtc->channel, true);
+
+	msleep(50);
+
+	dev_warn(dev->dev, "sync lost recovery done on on %s\n",
+		omap_crtc->name);
+
+	omap_crtc->ignore_sync_lost = false;
+	/* make sure the irq handler sees the value above */
+	mb();
+
+	drm_modeset_unlock(>mutex);
+}
+
 void omap_crtc_error_irq(struct drm_crtc *crtc, uint32_t irqstatus)
 {
 	struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+	struct drm_device *dev = omap_crtc->base.dev;
+	struct omap_drm_private *priv = dev->dev_private;
+	enum omap_channel channel = omap_crtc_channel(crtc);
+	u32 sync_lost_irq;
+	bool sync_lost;
+
+	sync_lost_irq = priv->dispc_ops->mgr_get_sync_lost_irq(channel);
 
-	if (omap_crtc->ignore_digit_sync_lost) {
-		irqstatus &= ~DISPC_IRQ_SYNC_LOST_DIGIT;
-		if (!irqstatus)
-			return;
+	sync_lost = irqstatus & sync_lost_irq;
+
+	if (sync_lost) {
+		if (omap_crtc->ignore_sync_lost) {
+			irqstatus &= ~sync_lost_irq;
+		} else {
+			/* error worker will set this to false */
+			omap_crtc->ignore_sync_lost = true;
+			schedule_work(_crtc->error_work);
+		}
 	}
 
-	DRM_ERROR_RATELIMITED("%s: errors: %08x\n", omap_crtc->name, irqstatus);
+	if (!irqstatus)
+		return;
+
+	printk("%s: errors: %08x\n", omap_crtc->name, irqstatus);
 }
 
 void omap_crtc_vblank_irq(struct drm_crtc *crtc)
@@ -612,6 +663,8 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
 
 	init_waitqueue_head(_crtc->pending_wait);
 
+	INIT_WORK(_crtc->error_work, omap_crtc_error_worker);
+
 	omap_crtc->channel = channel;
 	omap_crtc->name = channel_names[channel];
 
-- 
2.7.4



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tomi Valkeinen]

On 29/06/17 21:50, Aaro Koskinen wrote:
> Hi,
> 
> On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
>> On 15/06/17 01:11, Aaro Koskinen wrote:
>>> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
>>> is no display.
>>
>> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
>> check?
> 
> It appears the reason was that I didn't have
> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
> 
> I think that's wrong. I don't own an analog TV, so why should I enable
> such option to get device's built-in display working?

Indeed. Unfortunately I don't have a solution for that.

DRM doesn't support adding devices after probe. So at omapdrm probe time
we have to decide which displays to use. In the dts file, n900 defines
the lcd and analog tv. omapdrm sees those, and, of course, must wait
until their respective drivers have probed. If you don't have the
display driver enabled, it's never loaded and omapdrm never probes as it
keeps waiting for those.

omapdrm could start when some of the drivers are missing, but then the
question comes: when? omapdrm doesn't know if the driver will be probed
at some later time, or maybe it is a module, loaded later by the userspace.

So, unless the DRM framework is modified to support adding displays
after probe, I don't see a solution for this.

>> If that's the case then this is easier to debug.
> 
> Sure it's always easy... when users do all the testing and debugging.
> 
> Is it just me or do other OMAP users fail to see omapdrm changes being
> posted to linux-omap for testing or review purposes?

I thought linux-omap was more for omap platform thingies. But sure, I
can start cc'ing linux-omap for all omapdrm patches.

> And now I face another issue. When I boot v4.12-rc7 with
> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled and your "misc fixes"
> patches on N900, I get the error flood again, and the device is unusable:

Yes, I think there's still something wrong. I haven't been able to find
out what.

Somehow delays seem to help (like enabling debug prints), but I haven't
been able to find out where exactly the delay is needed.

And I'd rather not revert the patch, because there's nothing wrong with
that patch as such, and it fixes issues on all platforms.

So, I don't know... I guess I need to try to invent some horrible hacks
around the driver to somehow manage the omap3 problems. Perhaps
disabling/enabling the outputs when sync lost happens...

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> On 15/06/17 01:11, Aaro Koskinen wrote:
> > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > is no display.
> 
> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> check?

It appears the reason was that I didn't have
CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.

I think that's wrong. I don't own an analog TV, so why should I enable
such option to get device's built-in display working?

> If that's the case then this is easier to debug.

Sure it's always easy... when users do all the testing and debugging.

Is it just me or do other OMAP users fail to see omapdrm changes being
posted to linux-omap for testing or review purposes?

And now I face another issue. When I boot v4.12-rc7 with
CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled and your "misc fixes"
patches on N900, I get the error flood again, and the device is unusable:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.12.0-rc7-omap3-los_f343c+-3-g51d3478 
(aaro@amd-fx-6350) (gcc version 6.3.0 (GCC) ) #1 Thu Jun 29 21:40:29 EEST 2017
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache
[0.00] OF: fdt: Machine model: Nokia N900
[0.00] Memory policy: Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp)
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64770
[0.00] Kernel command line: console=ttyO2,115200 console=tty
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 242780K/261120K available (6144K kernel code, 210K 
rwdata, 1656K rodata, 6144K init, 1142K bss, 18340K reserved, 0K cma-reserved, 
0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xd000 - 0xff80   ( 760 MB)
[0.00] lowmem  : 0xc000 - 0xcff0   ( 255 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc070   (7136 kB)
[0.00]   .init : 0xc090 - 0xc0f0   (6144 kB)
[0.00]   .data : 0xc0f0 - 0xc0f34be0   ( 211 kB)
[0.00].bss : 0xc0f34be0 - 0xc1052560   (1143 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 
interrupts
[0.00] Clocking rate (Crystal/Core/MPU): 19.2/332/500 MHz
[0.00] OMAP clockevent source: timer1 at 32768 Hz
[0.00] clocksource: 32k_counter: mask: 0x max_cycles: 
0x, max_idle_ns: 58327039986419 ns
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 
6553584741ns
[0.00] OMAP clocksource: 32k_counter at 32768 Hz
[0.000488] Console: colour dummy device 80x30
[0.001281] console [tty0] enabled
[0.001342] Calibrating delay loop... 496.43 BogoMIPS (lpj=2482176)
[0.048370] pid_max: default: 32768 minimum: 301
[0.048553] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.048583] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.049468] CPU: Testing write buffer coherency: ok
[0.050354] Setting up static identity map for 0x8010 - 0x80100060
[0.053131] devtmpfs: initialized
[0.087066] VFP support v0.3: implementor 41 architecture 3 part 30 variant 
c rev 1
[0.087707] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.087799] futex hash table entries: 256 (order: -1, 3072 bytes)
[0.087982] pinctrl core: initialized pinctrl subsystem
[0.089599] NET: Registered protocol family 16
[0.091156] DMA: preallocated 256 KiB pool for atomic coherent allocations
[0.113800] omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp
[0.114562] omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp
[0.162780] Reprogramming SDRC clock to 33200 Hz
[0.177429] OMAP GPIO hardware version 2.5
[0.200073] irq: no irq domain found for 
/ocp@6800/l4@4800/scm@2000/pinmux@30 !
[0.215637] omap-gpmc 6e00.gpmc: could not find pctldev for node 
/ocp@6800/l4@4800/scm@2000/pinmux@30/pinmux_gpmc_pins, deferring probe
[0.219879] RX-51: Enabling ARM errata 430973 workaround
[0.221710] RX-51: Registering OMAP3 HWRNG device
[0.225158] 

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Thu, Jun 29, 2017 at 09:50:13PM +0300, Aaro Koskinen wrote:
> On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> > On 15/06/17 01:11, Aaro Koskinen wrote:
> > > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > > is no display.
> > 
> > Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> > check?
> 
> It appears the reason was that I didn't have
> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
> 
> I think that's wrong. I don't own an analog TV, so why should I enable
> such option to get device's built-in display working?
> 
> > If that's the case then this is easier to debug.
> 
> Sure it's always easy... when users do all the testing and debugging.
> 
> Is it just me or do other OMAP users fail to see omapdrm changes being
> posted to linux-omap for testing or review purposes?
> 
> And now I face another issue. When I boot v4.12-rc7 with
> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled and your "misc fixes"
> patches on N900, I get the error flood again, and the device is unusable:
> 
> [0.00] Booting Linux on physical CPU 0x0

For the record, here is my kernel config:

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.12.0-rc7 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_BANDGAP=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_VECTORS_BASE=0x
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION="-omap3"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_HANDLE_DOMAIN_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_CLOCKEVENTS=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
CONFIG_RCU_NEED_SEGCBLIST=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_GENERIC_SCHED_CLOCK=y
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
CONFIG_RD_XZ=y
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_POSIX_TIMERS=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_USERFAULTFD is not set
CONFIG_MEMBARRIER=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
# CONFIG_PC104 is not set

#
# 

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Thu, Jun 15, 2017 at 10:28:31AM +0300, Peter Ujfalusi wrote:
> On 2017-06-15 01:11, Aaro Koskinen wrote:
> > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > is no display.
> > 
> > Bisected to:
> > 
> > a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
> > commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
> > Author: Peter Ujfalusi 
> > Date:   Tue May 3 22:08:01 2016 +0300
> > 
> > drm/omap: Use omapdss_stack_is_ready() to check that the display stack 
> > is up
> > 
> > Instead of 'guessing' based on aliases of the status of the DSS drivers,
> > use the new interface to check that all needed drivers are loaded.
> > In this way we can be sure that all needed drivers are loaded so it is
> > safe to continue the probing of omapdrm.
> > This method will allow the omapdrm to be probed 'headless', without
> > outputs.
> > 
> > Signed-off-by: Peter Ujfalusi 
> > Signed-off-by: Tomi Valkeinen 
> > 
> > Reverting the commit seems to fix the issue.
> 
> When you revert this patch do you see a warning saying:
> "could not connect display: blah" ? if so what is 'blah'?

No.

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> On 15/06/17 01:11, Aaro Koskinen wrote:
> > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > is no display.
> 
> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> check? If that's the case then this is easier to debug.

Yes I think so, I added debug prints to omap_connect_dssdevs() and
pdev_probe(), and it's omapdss_stack_is_ready() that is failing.

> > Bisected to:
> > 
> > a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
> > commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
> > Author: Peter Ujfalusi 
> > Date:   Tue May 3 22:08:01 2016 +0300
> > 
> > drm/omap: Use omapdss_stack_is_ready() to check that the display stack 
> > is up
> > 
> > Instead of 'guessing' based on aliases of the status of the DSS drivers,
> > use the new interface to check that all needed drivers are loaded.
> > In this way we can be sure that all needed drivers are loaded so it is
> > safe to continue the probing of omapdrm.
> > This method will allow the omapdrm to be probed 'headless', without
> > outputs.
> > 
> > Signed-off-by: Peter Ujfalusi 
> > Signed-off-by: Tomi Valkeinen 
> > 
> > Reverting the commit seems to fix the issue.
> 
> This is probably "fixed" by adding the display aliases into the n900 dts
> file. The aliases should not really be required, although they are
> recommended. Without the aliases the order of the displays is random,
> and n900 could end up using tv-out as the first display. But even then,
> the displays should still work.

I'm using up-to-date DTS from the kernel tree.

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Peter Ujfalusi]

On 2017-06-15 01:11, Aaro Koskinen wrote:
> Hi,
> 
> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> is no display.
> 
> Bisected to:
> 
> a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
> commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
> Author: Peter Ujfalusi 
> Date:   Tue May 3 22:08:01 2016 +0300
> 
> drm/omap: Use omapdss_stack_is_ready() to check that the display stack is 
> up
> 
> Instead of 'guessing' based on aliases of the status of the DSS drivers,
> use the new interface to check that all needed drivers are loaded.
> In this way we can be sure that all needed drivers are loaded so it is
> safe to continue the probing of omapdrm.
> This method will allow the omapdrm to be probed 'headless', without
> outputs.
> 
> Signed-off-by: Peter Ujfalusi 
> Signed-off-by: Tomi Valkeinen 
> 
> Reverting the commit seems to fix the issue.

When you revert this patch do you see a warning saying:
"could not connect display: blah" ? if so what is 'blah'?

n900 have two displays afaik, LCD and TVout. omapdss_stack_is_ready() is
to ensure that we have all the drivers loaded for both displays, while
by reverting it it is enough if one of them is loaded at the time we do
the check and omapdrm would continue to probe, but the missing display
(even if it is going to be probed a bit later) will not work.

- Péter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tomi Valkeinen]

On 15/06/17 01:11, Aaro Koskinen wrote:
> Hi,
> 
> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> is no display.

Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
check? If that's the case then this is easier to debug.

> Bisected to:
> 
> a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
> commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
> Author: Peter Ujfalusi 
> Date:   Tue May 3 22:08:01 2016 +0300
> 
> drm/omap: Use omapdss_stack_is_ready() to check that the display stack is 
> up
> 
> Instead of 'guessing' based on aliases of the status of the DSS drivers,
> use the new interface to check that all needed drivers are loaded.
> In this way we can be sure that all needed drivers are loaded so it is
> safe to continue the probing of omapdrm.
> This method will allow the omapdrm to be probed 'headless', without
> outputs.
> 
> Signed-off-by: Peter Ujfalusi 
> Signed-off-by: Tomi Valkeinen 
> 
> Reverting the commit seems to fix the issue.

This is probably "fixed" by adding the display aliases into the n900 dts
file. The aliases should not really be required, although they are
recommended. Without the aliases the order of the displays is random,
and n900 could end up using tv-out as the first display. But even then,
the displays should still work.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel