On Thu, Feb 27, 2020 at 06:59:42PM +0200, Jani Nikula wrote:
> On Thu, 27 Feb 2020, Ross Zwisler <zwisler@xxxxxxxxxx> wrote:
> > On Thu, Feb 27, 2020 at 03:18:26PM +0200, Jani Nikula wrote:
> >> On Fri, 21 Feb 2020, José Roberto de Souza <jose.souza@xxxxxxxxx> wrote:
> >> > Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
> >> > once to enable PSR") was forcing the state compute too earlier
> >> > causing errors because not everything was initialized, so here
> >> > moving to the end of i915_driver_modeset_probe() when the display is
> >> > all initialized.
> >>
> >> Hmph, really not happy about the placement here. These are high level
> >> functions, not a dumping ground for random feature specific hacks. :(
> >
> > Should we just revert
> >
> > 60c6a14b489b ("drm/i915/display: Force the state compute phase once to enable PSR")
> >
> > and try to land a fixed-up version in the next kernel cycle? The current
> > state is that my machine is completely unable to boot because of this issue,
> > and I've confirmed that the above patch reverts cleanly and fixes the issue.
>
> IIUC this patch, already committed as df1a5bfc16f3 ("drm/i915/psr: Force
> PSR probe only after full initialization"), fixes the issue for you. At
> least the Tested-by says so. ;) So we should just go with that.
>
> I'm just being grumpy about the aesthetics of the implementation. I've
> already incorporated some cleanup to this in an existing refactoring I
> had [1].
Ah, sounds good. Sorry, I thought the fix hadn't been committed yet. :)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
