* Enabling i915.fastboot=1 by default @ 2018-06-06 9:09 Hans de Goede 2018-06-06 9:36 ` Maarten Lankhorst 0 siblings, 1 reply; 7+ messages in thread From: Hans de Goede @ 2018-06-06 9:09 UTC (permalink / raw) To: intel-gfx Hi All, So I'm working on making Linux boot in a complete flickerfree manner (no modesets, no black screens). I have this working on various machines with Intel gfx, but I need to pass i915.fastboot=1 on the kernel commandline. I know there was some talk about enabling this by default a while ago, but it seems that that still has not happened (yet?). I'm wondering what is holding this back ? Maybe we can change it from a bool to an int, init it to -1 and when it is -1 have some automatic detection code which disables it where it is known to be troublesome and otherwise enables it by default? Regards, Hans _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enabling i915.fastboot=1 by default 2018-06-06 9:09 Enabling i915.fastboot=1 by default Hans de Goede @ 2018-06-06 9:36 ` Maarten Lankhorst 2018-06-06 9:54 ` Hans de Goede 0 siblings, 1 reply; 7+ messages in thread From: Maarten Lankhorst @ 2018-06-06 9:36 UTC (permalink / raw) To: Hans de Goede, intel-gfx Op 06-06-18 om 11:09 schreef Hans de Goede: > Hi All, > > So I'm working on making Linux boot in a complete > flickerfree manner (no modesets, no black screens). > > I have this working on various machines with Intel > gfx, but I need to pass i915.fastboot=1 on the kernel > commandline. > > I know there was some talk about enabling this by > default a while ago, but it seems that that still > has not happened (yet?). > > I'm wondering what is holding this back ? Maybe we > can change it from a bool to an int, init it to -1 > and when it is -1 have some automatic detection > code which disables it where it is known to be > troublesome and otherwise enables it by default? Main reason are bugs like https://bugs.freedesktop.org/show_bug.cgi?id=103781 and our hw readout not being perfect. On some haswell/broadwell eDP laptops we stop generating vblanks when we fastboot, and in general we don't trust our code enough for that. The automatic detection code is already in place, we modeset if the mode is not compatible enough, but we don't catch all the cases where this might happen. ~Maarten _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enabling i915.fastboot=1 by default 2018-06-06 9:36 ` Maarten Lankhorst @ 2018-06-06 9:54 ` Hans de Goede 2018-06-06 10:43 ` Maarten Lankhorst 0 siblings, 1 reply; 7+ messages in thread From: Hans de Goede @ 2018-06-06 9:54 UTC (permalink / raw) To: Maarten Lankhorst, intel-gfx Hi, On 06-06-18 11:36, Maarten Lankhorst wrote: > Op 06-06-18 om 11:09 schreef Hans de Goede: >> Hi All, >> >> So I'm working on making Linux boot in a complete >> flickerfree manner (no modesets, no black screens). >> >> I have this working on various machines with Intel >> gfx, but I need to pass i915.fastboot=1 on the kernel >> commandline. >> >> I know there was some talk about enabling this by >> default a while ago, but it seems that that still >> has not happened (yet?). >> >> I'm wondering what is holding this back ? Maybe we >> can change it from a bool to an int, init it to -1 >> and when it is -1 have some automatic detection >> code which disables it where it is known to be >> troublesome and otherwise enables it by default? > > Main reason are bugs like https://bugs.freedesktop.org/show_bug.cgi?id=103781 and our hw > readout not being perfect. On some haswell/broadwell eDP laptops we stop generating vblanks > when we fastboot, and in general we don't trust our code enough for that. > > The automatic detection code is already in place, we modeset if the mode is not compatible > enough, but we don't catch all the cases where this might happen. Right but the "mode is not compatible" check will be always necessary, because e.g. some BIOs-es insist in bringing up the display in 1024x768 instead of its native mode. What I meant is, something like check which generation we are on (and maybe if a specific type of output is used or not if that does not convolute the code too much). E.g. you mention vblank issues with haswell/broadwell eDP, so if i915.fastboot=-1 we would then disable fastboot if we are on a haswell or broadwell and eDP is used. Or we could simply disable it on all haswell/broadwell devices when i915.fastboot=-1 used, but maybe enable on skylake and newer? Regards, Hans _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enabling i915.fastboot=1 by default 2018-06-06 9:54 ` Hans de Goede @ 2018-06-06 10:43 ` Maarten Lankhorst 2018-06-06 12:12 ` Hans de Goede 0 siblings, 1 reply; 7+ messages in thread From: Maarten Lankhorst @ 2018-06-06 10:43 UTC (permalink / raw) To: Hans de Goede, intel-gfx Op 06-06-18 om 11:54 schreef Hans de Goede: > Hi, > > On 06-06-18 11:36, Maarten Lankhorst wrote: >> Op 06-06-18 om 11:09 schreef Hans de Goede: >>> Hi All, >>> >>> So I'm working on making Linux boot in a complete >>> flickerfree manner (no modesets, no black screens). >>> >>> I have this working on various machines with Intel >>> gfx, but I need to pass i915.fastboot=1 on the kernel >>> commandline. >>> >>> I know there was some talk about enabling this by >>> default a while ago, but it seems that that still >>> has not happened (yet?). >>> >>> I'm wondering what is holding this back ? Maybe we >>> can change it from a bool to an int, init it to -1 >>> and when it is -1 have some automatic detection >>> code which disables it where it is known to be >>> troublesome and otherwise enables it by default? >> >> Main reason are bugs like https://bugs.freedesktop.org/show_bug.cgi?id=103781 and our hw >> readout not being perfect. On some haswell/broadwell eDP laptops we stop generating vblanks >> when we fastboot, and in general we don't trust our code enough for that. >> >> The automatic detection code is already in place, we modeset if the mode is not compatible >> enough, but we don't catch all the cases where this might happen. > > Right but the "mode is not compatible" check will be always > necessary, because e.g. some BIOs-es insist in bringing > up the display in 1024x768 instead of its native mode. It's not just the mode we're checking, any parameter in intel_pipe_config_compare is checked and adjusted. This code is also run after each modeset. If the panel fitter is used we don't need to modeset from 1024x768, we will just disable the panel fitter. > What I meant is, something like check which generation we are on > (and maybe if a specific type of output is used or not if that > does not convolute the code too much). > > E.g. you mention vblank issues with haswell/broadwell eDP, > so if i915.fastboot=-1 we would then disable fastboot > if we are on a haswell or broadwell and eDP is used. I think we shouldn't put any code in adding workarounds or detection, but fix those bugs and then retry enabling things. > Or we could simply disable it on all haswell/broadwell devices > when i915.fastboot=-1 used, but maybe enable on skylake and > newer? First step is making sure we use the code for everything except the initial modeset, already had a patch for that, but it needs some fixing since new warnings pop up.. https://patchwork.freedesktop.org/series/43248/ _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enabling i915.fastboot=1 by default 2018-06-06 10:43 ` Maarten Lankhorst @ 2018-06-06 12:12 ` Hans de Goede 2018-06-06 18:12 ` Rodrigo Vivi 0 siblings, 1 reply; 7+ messages in thread From: Hans de Goede @ 2018-06-06 12:12 UTC (permalink / raw) To: Maarten Lankhorst, intel-gfx Hi, On 06-06-18 12:43, Maarten Lankhorst wrote: > Op 06-06-18 om 11:54 schreef Hans de Goede: >> Hi, >> >> On 06-06-18 11:36, Maarten Lankhorst wrote: >>> Op 06-06-18 om 11:09 schreef Hans de Goede: >>>> Hi All, >>>> >>>> So I'm working on making Linux boot in a complete >>>> flickerfree manner (no modesets, no black screens). >>>> >>>> I have this working on various machines with Intel >>>> gfx, but I need to pass i915.fastboot=1 on the kernel >>>> commandline. >>>> >>>> I know there was some talk about enabling this by >>>> default a while ago, but it seems that that still >>>> has not happened (yet?). >>>> >>>> I'm wondering what is holding this back ? Maybe we >>>> can change it from a bool to an int, init it to -1 >>>> and when it is -1 have some automatic detection >>>> code which disables it where it is known to be >>>> troublesome and otherwise enables it by default? >>> >>> Main reason are bugs like https://bugs.freedesktop.org/show_bug.cgi?id=103781 and our hw >>> readout not being perfect. On some haswell/broadwell eDP laptops we stop generating vblanks >>> when we fastboot, and in general we don't trust our code enough for that. >>> >>> The automatic detection code is already in place, we modeset if the mode is not compatible >>> enough, but we don't catch all the cases where this might happen. >> >> Right but the "mode is not compatible" check will be always >> necessary, because e.g. some BIOs-es insist in bringing >> up the display in 1024x768 instead of its native mode. > > It's not just the mode we're checking, any parameter in intel_pipe_config_compare is > checked and adjusted. This code is also run after each modeset. If the panel fitter is > used we don't need to modeset from 1024x768, we will just disable the panel fitter. > >> What I meant is, something like check which generation we are on >> (and maybe if a specific type of output is used or not if that >> does not convolute the code too much). >> >> E.g. you mention vblank issues with haswell/broadwell eDP, >> so if i915.fastboot=-1 we would then disable fastboot >> if we are on a haswell or broadwell and eDP is used. > > I think we shouldn't put any code in adding workarounds or detection, but fix > those bugs and then retry enabling things. But enabling it for all generations at once feels to me like we will never end up enabling it because of an issue on some generations only. There are plenty of other cases where features are enabled by default on a generation by generation basis. I agree that ideally we end up enabling this everywhere, but enabling it by default everywhere at once feel like you are aiming a bit too high. >> Or we could simply disable it on all haswell/broadwell devices >> when i915.fastboot=-1 used, but maybe enable on skylake and >> newer? > First step is making sure we use the code for everything except the initial modeset, already had a patch for that, > but it needs some fixing since new warnings pop up.. > > https://patchwork.freedesktop.org/series/43248/ That sounds like a good first step, I'm afraid I don't have time to look into the test failures myself. If you have some time to take a second look at this that would be great. Regards, Hans _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enabling i915.fastboot=1 by default 2018-06-06 12:12 ` Hans de Goede @ 2018-06-06 18:12 ` Rodrigo Vivi 2018-06-07 9:11 ` Hans de Goede 0 siblings, 1 reply; 7+ messages in thread From: Rodrigo Vivi @ 2018-06-06 18:12 UTC (permalink / raw) To: Hans de Goede; +Cc: intel-gfx On Wed, Jun 06, 2018 at 02:12:36PM +0200, Hans de Goede wrote: > Hi, > > On 06-06-18 12:43, Maarten Lankhorst wrote: > > Op 06-06-18 om 11:54 schreef Hans de Goede: > > > Hi, > > > > > > On 06-06-18 11:36, Maarten Lankhorst wrote: > > > > Op 06-06-18 om 11:09 schreef Hans de Goede: > > > > > Hi All, > > > > > > > > > > So I'm working on making Linux boot in a complete > > > > > flickerfree manner (no modesets, no black screens). > > > > > > > > > > I have this working on various machines with Intel > > > > > gfx, but I need to pass i915.fastboot=1 on the kernel > > > > > commandline. > > > > > > > > > > I know there was some talk about enabling this by > > > > > default a while ago, but it seems that that still > > > > > has not happened (yet?). > > > > > > > > > > I'm wondering what is holding this back ? Maybe we > > > > > can change it from a bool to an int, init it to -1 > > > > > and when it is -1 have some automatic detection > > > > > code which disables it where it is known to be > > > > > troublesome and otherwise enables it by default? > > > > > > > > Main reason are bugs like https://bugs.freedesktop.org/show_bug.cgi?id=103781 and our hw > > > > readout not being perfect. On some haswell/broadwell eDP laptops we stop generating vblanks > > > > when we fastboot, and in general we don't trust our code enough for that. > > > > > > > > The automatic detection code is already in place, we modeset if the mode is not compatible > > > > enough, but we don't catch all the cases where this might happen. > > > > > > Right but the "mode is not compatible" check will be always > > > necessary, because e.g. some BIOs-es insist in bringing > > > up the display in 1024x768 instead of its native mode. > > > > It's not just the mode we're checking, any parameter in intel_pipe_config_compare is > > checked and adjusted. This code is also run after each modeset. If the panel fitter is > > used we don't need to modeset from 1024x768, we will just disable the panel fitter. > > > > > What I meant is, something like check which generation we are on > > > (and maybe if a specific type of output is used or not if that > > > does not convolute the code too much). > > > > > > E.g. you mention vblank issues with haswell/broadwell eDP, > > > so if i915.fastboot=-1 we would then disable fastboot > > > if we are on a haswell or broadwell and eDP is used. > > > > I think we shouldn't put any code in adding workarounds or detection, but fix > > those bugs and then retry enabling things. > > But enabling it for all generations at once feels to me like > we will never end up enabling it because of an issue on some > generations only. There are plenty of other cases where > features are enabled by default on a generation by generation > basis. I agree that ideally we end up enabling this everywhere, > but enabling it by default everywhere at once feel like you > are aiming a bit too high. I agree with Hans on this point. It is not a matter of workaround or detection, but a matter of bandwidth to deal with validation and incoming bugs, specially when the behaviour changes for different gens. On the PSR front, for instance, we are focused on enabling first on SKL and expand that for other platforms. > > > > Or we could simply disable it on all haswell/broadwell devices > > > when i915.fastboot=-1 used, but maybe enable on skylake and > > > newer? > > First step is making sure we use the code for everything except the initial modeset, already had a patch for that, > > but it needs some fixing since new warnings pop up.. > > > > https://patchwork.freedesktop.org/series/43248/ > > That sounds like a good first step, I'm afraid I don't have time to > look into the test failures myself. If you have some time to > take a second look at this that would be great. > > Regards, > > Hans > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enabling i915.fastboot=1 by default 2018-06-06 18:12 ` Rodrigo Vivi @ 2018-06-07 9:11 ` Hans de Goede 0 siblings, 0 replies; 7+ messages in thread From: Hans de Goede @ 2018-06-07 9:11 UTC (permalink / raw) To: Rodrigo Vivi; +Cc: intel-gfx Hi, On 06-06-18 20:12, Rodrigo Vivi wrote: > On Wed, Jun 06, 2018 at 02:12:36PM +0200, Hans de Goede wrote: >> Hi, >> >> On 06-06-18 12:43, Maarten Lankhorst wrote: >>> Op 06-06-18 om 11:54 schreef Hans de Goede: >>>> Hi, >>>> >>>> On 06-06-18 11:36, Maarten Lankhorst wrote: >>>>> Op 06-06-18 om 11:09 schreef Hans de Goede: >>>>>> Hi All, >>>>>> >>>>>> So I'm working on making Linux boot in a complete >>>>>> flickerfree manner (no modesets, no black screens). >>>>>> >>>>>> I have this working on various machines with Intel >>>>>> gfx, but I need to pass i915.fastboot=1 on the kernel >>>>>> commandline. >>>>>> >>>>>> I know there was some talk about enabling this by >>>>>> default a while ago, but it seems that that still >>>>>> has not happened (yet?). >>>>>> >>>>>> I'm wondering what is holding this back ? Maybe we >>>>>> can change it from a bool to an int, init it to -1 >>>>>> and when it is -1 have some automatic detection >>>>>> code which disables it where it is known to be >>>>>> troublesome and otherwise enables it by default? >>>>> >>>>> Main reason are bugs like https://bugs.freedesktop.org/show_bug.cgi?id=103781 and our hw >>>>> readout not being perfect. On some haswell/broadwell eDP laptops we stop generating vblanks >>>>> when we fastboot, and in general we don't trust our code enough for that. >>>>> >>>>> The automatic detection code is already in place, we modeset if the mode is not compatible >>>>> enough, but we don't catch all the cases where this might happen. >>>> >>>> Right but the "mode is not compatible" check will be always >>>> necessary, because e.g. some BIOs-es insist in bringing >>>> up the display in 1024x768 instead of its native mode. >>> >>> It's not just the mode we're checking, any parameter in intel_pipe_config_compare is >>> checked and adjusted. This code is also run after each modeset. If the panel fitter is >>> used we don't need to modeset from 1024x768, we will just disable the panel fitter. >>> >>>> What I meant is, something like check which generation we are on >>>> (and maybe if a specific type of output is used or not if that >>>> does not convolute the code too much). >>>> >>>> E.g. you mention vblank issues with haswell/broadwell eDP, >>>> so if i915.fastboot=-1 we would then disable fastboot >>>> if we are on a haswell or broadwell and eDP is used. >>> >>> I think we shouldn't put any code in adding workarounds or detection, but fix >>> those bugs and then retry enabling things. >> >> But enabling it for all generations at once feels to me like >> we will never end up enabling it because of an issue on some >> generations only. There are plenty of other cases where >> features are enabled by default on a generation by generation >> basis. I agree that ideally we end up enabling this everywhere, >> but enabling it by default everywhere at once feel like you >> are aiming a bit too high. > > I agree with Hans on this point. It is not a matter of workaround > or detection, but a matter of bandwidth to deal with validation and > incoming bugs, specially when the behaviour changes for different > gens. Ok, so perhaps we can try to enable this now on some hardware? Say skylake+ and byt + cht + apollo-lake ? Regards, Hans _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-06-07 9:11 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-06-06 9:09 Enabling i915.fastboot=1 by default Hans de Goede 2018-06-06 9:36 ` Maarten Lankhorst 2018-06-06 9:54 ` Hans de Goede 2018-06-06 10:43 ` Maarten Lankhorst 2018-06-06 12:12 ` Hans de Goede 2018-06-06 18:12 ` Rodrigo Vivi 2018-06-07 9:11 ` Hans de Goede
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.