On Thu, Sep 28, 2017 at 10:51:42AM +0000, David Weinehall wrote: > On Thu, Sep 28, 2017 at 04:20:29AM +0000, Rodrigo Vivi wrote: > > On Wed, Sep 27, 2017 at 5:14 AM David Weinehall < > > david.weinehall@xxxxxxxxxxxxxxx> wrote: > > > > > On Tue, Aug 08, 2017 at 12:50:51PM -0700, Rodrigo Vivi wrote: > > > > a long time ago I had agreed with Daniel that we would only add new > > > > platforms after it was enabled by default on previous platforms. > > > > a big reason for that is that we was willing to reduce the platforms > > > > to validate and do better validation one by one before enabling. > > > > > > > > However now I believe it would be beneficial to have that supported > > > > added so we can get more brave people using in different platforms so > > > > we could capture more corner cases before we enable it by default. > > > > Also we can still enable by default one platform at time if needed. > > > > > > > > So: > > > > > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > > > > > > > I also checked the spec to see if there was anything else new or > > > > different for these platforms and didn't find anything so: > > > > > > > > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > > > > > > > But let's wait a bit to merge to give Daniel or others a time to nack ;) > > > > > > An update: while testing revealed that our BXT-P RVP doesn't work with > > > PSR, the GLK definitely does. CI would like to do PSR testing on GLK, > > > which obviously isn't possible if PSR is reported as unsupported on GLK. > > > > > > Based on BSpec alone the PSR failure on BXT-P shouldn't be a > > > Broxton/Apollo Lake issue, but rather an issue with the RVP board > > > (or the panel), so I'd say that this patch still makes sense. > > > > > > It would be very important if we could narrow down the issue on BXT. > > Panel?! Bios?! Missing Workaround? Different user space? > > Agreed. I haven't been able to find any newer BIOS for that device, > the user space should be the same. > > Missing workaround might well be the case, and the panel is definitely > not the same as the one the GLK has. We have several other panels that > could be tested with though. > > > One of the biggest problem with PSR is that when it works well in all > > machines we have and we enable it we end up finding someone in the > > community with a machine that does not work well. > > "Luckily" I own one of those machines :P > > > We have an opportunity to investigate and understand very well what > > are the issues on this BXT. We shouldn't loose track of it. > > That opportunity is now rapidly fleeing, since the HW in > question is a BXT B0, for which the "drop workarounds" patch series > has already been submitted and gotten a R-B. Agree. But since it was a while ago I was trying to hit CI retest on that, but I couldn't. So could you please resubmit? I just want to see if that will cause some noise that will force us to file a bug so CI doesn't start flip-floping again because of this. > > > And maybe adding that to CI we will be forced to record the bug! ;) > > > > > > > > After all it only changes gen9lp to report that they *can* support PSR > > > (thus allowing for testing of PSR on such platforms), it doesn't enable > > > it by default. > > > > > > So I'd like to nudge once more that this patch be merged. > > > > I agree. Let's add it. Also good to enable on CNL as well. If the panel > > that you have there on CNL that is on CI doesn't support it you are about > > to recurve some panels that does support PSR2. > > Yeah, enabling on CNL too makes sense and getting systematic PSR2 testing > would be awesome. nevermind... on another review I notice cnl is already there imported from HSW_FEATURES. > > "recurve" => "receive"? yeap... (phone auto-corrector believe recurve is the best option for recieve than receive :)) Thanks, Rodrigo. > > > Kind regards, David _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
