Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751952AbdF3Gmi (ORCPT ); Fri, 30 Jun 2017 02:42:38 -0400 Received: from fllnx209.ext.ti.com ([198.47.19.16]:21089 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751613AbdF3Gmh (ORCPT ); Fri, 30 Jun 2017 02:42:37 -0400 Subject: Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900 To: Aaro Koskinen , Peter Ujfalusi CC: Tony Lindgren , , , References: <20170614221133.k7gmbzzjsbmbjgbc@darkstar.musicnaut.iki.fi> <20170629185013.aec7qhvrl3waifww@darkstar.musicnaut.iki.fi> From: Tomi Valkeinen Message-ID: Date: Fri, 30 Jun 2017 09:41:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170629185013.aec7qhvrl3waifww@darkstar.musicnaut.iki.fi> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5dFrG342KQBUWtulI9vlF0vwwjTeujqlh" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4521 Lines: 113 --5dFrG342KQBUWtulI9vlF0vwwjTeujqlh Content-Type: multipart/mixed; boundary="CB29ADuEFKGem6QQEwsSxweHRddhDi3Ox"; protected-headers="v1" From: Tomi Valkeinen To: Aaro Koskinen , Peter Ujfalusi Cc: Tony Lindgren , linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, dri-devel@lists.freedesktop.org Message-ID: Subject: Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900 References: <20170614221133.k7gmbzzjsbmbjgbc@darkstar.musicnaut.iki.fi> <20170629185013.aec7qhvrl3waifww@darkstar.musicnaut.iki.fi> In-Reply-To: <20170629185013.aec7qhvrl3waifww@darkstar.musicnaut.iki.fi> --CB29ADuEFKGem6QQEwsSxweHRddhDi3Ox Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 29/06/17 21:50, Aaro Koskinen wrote: > Hi, >=20 > 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 ther= e >>> is no display. >> >> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready() >> check? >=20 > It appears the reason was that I didn't have > CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled. >=20 > 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 userspac= e. 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. >=20 > Sure it's always easy... when users do all the testing and debugging. >=20 > 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 unusabl= e: 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 --CB29ADuEFKGem6QQEwsSxweHRddhDi3Ox-- --5dFrG342KQBUWtulI9vlF0vwwjTeujqlh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZVfKfAAoJEPo9qoy8lh71OjwP/0iwQX0alhBiaFp3L28brJvo 8m41MevR3q24aaoQ9lEUizsheeIrjQqFv9hoG0ZEwWKAkYAqyToA+y8LcjOYAOxV OmBkIyDBbAzxuhLXglvotQI8Sxw9nS7Xc05apLfwZktlfmp/ifFJOHqGy02dCu9I SWVweI9I5WKETF9Rhd9muzm+QTAkel2X0rHo1CW799TsoKVOEailj8DPi+6sUAxv +oKSGAHzWczSfYszYvTv20lQyGNPDaXXn3WoI5WMgcbdqg7nQnX1pArcppt/MnIC Sz/V/2puW9wQSP6u2/m/RWDbO3m7WX7EvxaZ7FGbozfFv+c36vpJuC3P4JXNxumS ejFhG5PKsDwRb+503UJ/PLWLWVoUty6KaT4OPAAu20cpzfmRBysMduXQ0vpRsUS/ sQQKdoKjCx5fiMG9LVIfNQENv4hG09TYGD1/6cuGqoQIrMlFzw6qFgq0gejqE6DK IxNfDbj+Ru+VhDM9KIeIuwsOhb1sa77HLOkBAzp3ziXgBF5T6wW2nbmWrrzSCq4Z R7x8deuH5c6ru8nf1oFz4X0IHmvPQ2H3OHSAoOmEyHH1RDuZjekjn5wwCZFX6IUA S6xLllCWgVtkV73IZnvZAHLAChOLCvUNvaXe67SZ7G0uWzxx+2PoCsFxMBFQFf82 ZGUukuBj+ygm+j6OBRCQ =LF4U -----END PGP SIGNATURE----- --5dFrG342KQBUWtulI9vlF0vwwjTeujqlh--