| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 30 Sep 2020 16:25:49 -0400
From: Lyude Paul <lyude@...hat.com>
To: Kevin Chowski <chowski@...omium.org>
Cc: Jani Nikula <jani.nikula@...ux.intel.com>,
Puthikorn Voravootivat <puthik@...omium.org>,
Ville Syrjälä
<ville.syrjala@...ux.intel.com>, David Airlie <airlied@...ux.ie>,
intel-gfx <intel-gfx@...ts.freedesktop.org>,
LKML <linux-kernel@...r.kernel.org>,
dri-devel@...ts.freedesktop.org,
Wambui Karuga <wambui.karugax@...il.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Juha-Pekka Heikkila <juhapekka.heikkila@...il.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Hans de Goede <hdegoede@...hat.com>,
Daniel Vetter <daniel@...ll.ch>
Subject: Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP
brightness.
On Tue, 2020-09-29 at 13:32 -0600, Kevin Chowski wrote:
> Thank you for the reply. And in regards to digging into it further,
> thanks for requesting that I do some more due diligence here :)
>
> Also if you did get around to it, thanks for double-checking with
> Bill! Let me know if you'd like me to reach out instead, or if
> anything else needs to be done in this regard.
>
> So to clarify the plan: if we do actually move forwards with leaving
> the current functionality as the default, do we need to have the
> complete list of devices which need the quirk applied when the patch
> first goes in? From my perspective, we definitely have one device
> which needs the quirk (and preferably, it'd be good to do it sooner
> than later so that we can get this bugfix out to our users) and an
> unknowable number of others. Would it be OK to introduce the quirk for
> just Pixelbook and to follow up to add others once we have that list?
Totally-I've got no problem with this.
> It may take a good amount of time for me to herd the cats inside
> Google, especially given there's a chance that there are affected
> laptops and that no one has noticed (e.g., I almost didn't notice with
> the Pixelbook). Given Lyude's analysis it seems like Chrome OS devices
> may be the largest affected group here, so I am incentivized to not
> drop the ball after fixing my immediate Pixelbook problem :)
>
> On Fri, Sep 25, 2020 at 10:53 AM Lyude Paul <lyude@...hat.com> wrote:
> > On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote:
> > > cc back a few others who were unintentionally dropped from the thread
> > > earlier.
> > >
> > > Someone (at Google) helped me dig into this a little more and they
> > > found a document titled "eDP Backlight Brightness bit alignment" sent
> > > out for review in January 2017. I registered for a new account (google
> > > is a member) and have access to the document; here is the URL for
> > > those who also have access:
> > > https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth,
> > > it seems like Lyude's contact Bill Lempesis uploaded this
> > > change-request document, so I think we can reach out to him if we have
> > > further questions. It's actually unclear to me what the status of this
> > > change request is, and whether it's been officially accepted. But I
> > > think it can be seen as some official advice on how we can move
> > > forward here.
> > >
> > > Basically, this is a change request to the spec which acknowledges
> > > that, despite the original spec implying that the
> > > most-significant-bits were relevant here, many implementations used
> > > the least-significant-bits. In defense of most-significant it laid out
> > > some similar arguments to what Ville was saying. But it ends up
> > > saying:
> > >
> > > > Unfortunately, the most common interpretation that we have
> > > > encountered is case 1 in the example above. TCON vendors
> > > > tend to align the valid bits to the LSBs, not the MSBs.
> > >
> > > Instead of changing the default defined functionality (as some earlier
> > > version of this doc apparently suggested), this doc prefers to
> > > allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future
> > > backlight devices can specify to the Source how to program them:
> > >
> > > 00: the current functionality, i,e. no defined interpretation
> > > 01: aligned to most-significant bits
> > > 10: aligned to least-significant bits
> > > 11: reserved
> > >
> > > It also says "[Sources] should only need panel-specific workarounds
> > > for the currently available panels."
> > >
> > > So I believe this document is an acknowledgement of many
> > > implementations having their alignment to the least-significant bits,
> > > and (to my eyes) clearly validates that the spec "should" be the
> > > opposite. If we believe the doc's claim that "the most common
> > > interpretation" is least-significant, it seems to me that it would
> > > require more quirks if we made most-significant the default
> > > implementation.
> > >
> > > Ville mentioned at some point earlier that we should try to match the
> > > spec, whereas Lyude mentioned we should prefer to do what the majority
> > > of machines do. What do you both think of this new development?
> >
> > That's how displayport happens to be sometimes :). Definitely isn't the
> > first
> > time something in the spec like this got implemented incorrectly so many
> > times
> > by different vendors that they had to update the spec in response (same
> > thing
> > happened with MST and interleaved sideband messages as of DP 2.0), so I'm
> > really glad we went and actually investigated this.
> >
> > So yes - I think a quirk for this would definitely be a good idea, and IMO
> > we
> > should always lean on the side that more panels implement even if it's not
> > according to spec - so defaulting to the behavior we currently have in the
> > kernel, and adding quirks for panels that were smart enough not to fall for
> > this would probably be the best way to go. That just leaves the challenge of
> > "how do we figure out which panels actually need this and which ones don't?"
> >
> > This might end up being a bit of a challenge, but I've got some ideas on how
> > we might be able to tackle it to the best of our ability based off my
> > discussions with laptop vendors. It seems like some of the homegrown
> > backlight
> > interfaces might help us out here. Note I'm mentioning other laptop vendors
> > here because at least for nouveau, our plan for DPCD backlight support is to
> > move a lot of the code for handling it that currently lives in i915 into
> > shared DRM helpers (which now we'll definitely need to do as a result of
> > these
> > quirks).
> >
> > So, on the x86 front, there's already a few different interfaces in use for
> > laptop panels:
> > * AMD usually uses their own backlight interface, so for AMD-only laptops
> > we
> > can probably safely ignore this
> > * Intel uses their own DPCD backlight interface on most of the _non-
> > ChromeOS_
> > machines on the market right now afaik based off my discussion with some
> > laptop vendors. For panels that only come up in Intel-only machines, that
> > means we only really need to care about the ChromeOS case here. So-if
> > Google's able to actually survey the devices they're shipping with
> > ChromeOS
> > right now to figure out which ones are using DPCD backlight controls, and
> > which ones need to be MSB aligned - then I'd think we could probably
> > build
> > an accurate quirk list of those panels easily.
> > * This just leaves the nvidia case. Nvidia seems to be one of the only GPU
> > vendors that didn't come up with their own backlight interface over DPCD,
> > and they actually require that the panel support the VESA backlight
> > control
> > interface. Incidentally, a lot of the laptops that I've force-enabled
> > VESA
> > backlight controls on have nvidia GPUs in them, and so far every single
> > one
> > has worked with the code we currently use in the kernel. My hope with
> > this
> > would be that since nvidia's driver support is somewhat consistent, they
> > either might have a list of problematic panels or can just verify with us
> > that all of the panels that their driver interacts with follow the LSB
> > preference.
> >
> > For the ChromeOS guys in the thread, does this sound like it could be
> > workable? For the time being, I'll also send my nvidia contacts a poke to
> > see
> > what info they can give us. As well, we should probably poke Bill just in
> > case
> > he might know of some resource that documents some of the problematic panels
> > out there (probably not, but it's at least worth a shot). I'll try to get
> > around this today, but we might have to poke him once or twice since there
> > originally was a problem with any of the emails from Red Hat getting through
> > to him…
> >
> > > I will also look into whether my specific device supports this
> > > extension, and in that case I'll volunteer to implement this new
> > > functionality in the driver.
> > >
> > > Thanks for your time,
> > > Kevin
> > >
> > > On Tue, Sep 22, 2020 at 3:30 PM Lyude Paul <lyude@...hat.com> wrote:
> > > > Hi! Since I got dropped from the thread, many responses inline
> > > >
> > > > On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> > > > > +Lyude
> > > > > I notice that Lyude email was somehow dropped from the thread.
> > > > > Lyude was the person who submitted the patch for Thinkpad and should
> > > > > know the OUI of the panel.
> > > >
> > > > no need - currently because of some confusion that got caused by the
> > > > Intel
> > > > HDR
> > > > backlight interface being the only backlight interface that works
> > > > properly
> > > > on
> > > > a lot of panels (many panels will advertise both interfaces, but might
> > > > only
> > > > work with the Intel one), we actually rely on a small allowlist of
> > > > "approved"
> > > > panels for enabling DPCD backlight control.
> > > >
> > > > …however, many of these panels are annoying and don't actually provide a
> > > > reliable enough OUID to use for quirk detection, which is why we had to
> > > > add
> > > > EDID quirk detection as a temporary workaround for this. The current
> > > > list
> > > > of
> > > > panels lives in drm_dp_helper.c:
> > > >
> > > > /*
> > > > * Some devices have unreliable OUIDs where they don't set the device ID
> > > > * correctly, and as a result we need to use the EDID for finding
> > > > additional
> > > > * DP quirks in such cases.
> > > > */
> > > > static const struct edid_quirk edid_quirk_list[] = {
> > > > /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd
> > > > Generation
> > > > * only supports DPCD backlight controls
> > > > */
> > > > { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
> > > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > > > /*
> > > > * Some Dell CML 2020 systems have panels support both AUX and
> > > > PWM
> > > > * backlight control, and some only support AUX backlight
> > > > control.
> > > > All
> > > > * said panels start up in AUX mode by default, and we don't
> > > > have
> > > > any
> > > > * support for disabling HDR mode on these panels which would be
> > > > * required to switch to PWM backlight control mode (plus, I'm
> > > > not
> > > > * even sure we want PWM backlight controls over DPCD backlight
> > > > * controls anyway...). Until we have a better way of detecting
> > > > these,
> > > > * force DPCD backlight mode on all of them.
> > > > */
> > > > { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32),
> > > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > > > { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41),
> > > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > > > { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
> > > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > > > { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14),
> > > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > > > { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41),
> > > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > > > };
> > > >
> > > > Also note that I think just about every panel on that list supports the
> > > > Intel
> > > > HDR backlight interface, so it's -possible- that the VESA interface
> > > > could
> > > > be
> > > > broken on these panels. But, that would be a lot of different panels
> > > > from
> > > > different vendors to all be broken in the same way.
> > > >
> > > > > On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski <chowski@...omium.org>
> > > > > wrote:
> > > > > > Alrighty, I'll take everyone else's silence as tacit approval of
> > > > > > Ville's opinions. (I didn't receive any email bounces this time, so
> > > > > > I
> > > > > > think my issue was transient.) I will start on inverting the quirk
> > > > > > and
> > > > > > making the most-significant-alignment matter for these registers by
> > > > > > default.
> > > > > >
> > > > > > Who can help me gather a list of OUIs that we need to add to the
> > > > > > quirk? I can follow up with Puthikorn about the relevant
> > > > > > Chromebooks,
> > > > > > but I don't know what other types of laptops are using this driver.
> > > > > >
> > > > > > Thanks for your time,
> > > > > > Kevin Chowski
> > > > > >
> > > > > >
> > > > > > On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
> > > > > > <puthik@...omium.org> wrote:
> > > > > > > I'll defer to Ville & Lyude.
> > > > > > >
> > > > > > > I dug up more on the bug report and found that both Thinkpad and
> > > > > > > Galaxy Chromebook use the same Samsung OLED.
> > > > > > > So my 2 vs 1 argument is actually not valid.
> > > > > > >
> > > > > > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski <
> > > > > > > chowski@...omium.org
> > > > > > > wrote:
> > > > > > > > Apologies once again, some of my emails were bouncing for some
> > > > > > > > addresses yesterday. Hopefully it was a temporary condition;
> > > > > > > > I'll
> > > > > > > > continue trying to dig into it on my end if it happens again for
> > > > > > > > this
> > > > > > > > email.
> > > > > > > >
> > > > > > > > Since there's evidence that some models want lsb and some (well,
> > > > > > > > at
> > > > > > > > least one) want msb, my understanding is that we'll need a quirk
> > > > > > > > one
> > > > > > > > way or the other (please correct if I'm mistaken). I
> > > > > > > > unfortunately
> > > > > > > > don't have the ability to test anything other than the
> > > > > > > > Pixelbook,
> > > > > > > > so
> > > > > > > > if we decide the msb is the "right" way, then I will have to
> > > > > > > > rely
> > > > > > > > on
> > > > > > > > others to test (and find the OUI of) other models which require
> > > > > > > > lsb.
> > > > > > > >
> > > > > > > > I am happy to make any changes requested, but I do not at all
> > > > > > > > have
> > > > > > > > enough background here to make the decision on whether the msb
> > > > > > > > functionality deserves the quirk or if the lsb one does. How can
> > > > > > > > I
> > > > > > > > help you all come to an agreement here?
> > > > > > > >
> > > > > > > > * It seems like Ville feels strongly about the msb being the
> > > > > > > > correct
> > > > > > > > interpretation of the spec.
> > > > > > > > * It's unclear to me on which side of the fence Lyude falls, I
> > > > > > > > couldn't pick up a strong opinion in her clarifying question.
> > > > > > > > * Puthikorn seems to be on the side of lsb being correct, but
> > > > > > > > maybe
> > > > > > > > was swayed by Ville's argument.
> > > >
> > > > Honestly I'm not hard to convince :P, if it looks like we got the bit
> > > > shift
> > > > wrong for the majority of devices and everyone else agrees then I'm fine
> > > > with
> > > > assuming that's the case. I'm just quite surprised, seeing as we've
> > > > tested
> > > > many different panels from a few vendors and haven't run into any issues
> > > > with
> > > > this before.
> > > >
> > > > Honestly - if there's this much uncertainty about it, maybe we should
> > > > just
> > > > ask
> > > > VESA directly what the correct interpretation of this is? Note I'm not
> > > > on
> > > > the
> > > > VESA board (I get access to DP/eDP specs through X.org) so unless the
> > > > contacts
> > > > I've got from VESA would work (Bill Lempesis bill at vesa dot org) for
> > > > that it
> > > > might be a better idea for someone from Google or Intel to ask.
> > > >
> > > > > > > > If no one feels that Ville's argument is not strong in some way,
> > > > > > > > and
> > > > > > > > we go with that, I will get to work on the requested changes. I
> > > > > > > > am
> > > > > > > > concerned, though, about changing the default functionality
> > > > > > > > without
> > > > > > > > testing it widely to find the set of laptops which require the
> > > > > > > > lsb
> > > > > > > > quirk. I'd appreciate any advice people might have about making
> > > > > > > > this
> > > > > > > > change safely.
> > > >
> > > > Usually, I just try to stick with what the majority of machines need to
> > > > do. I
> > > > still think it'd be a good idea for us to verify this with VESA if
> > > > there's
> > > > that much confusion though
> > > >
> > > > > > > > Thank you for your time,
> > > > > > > > Kevin
> > > > > > > >
> > > > > > > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
> > > > > > > > <ville.syrjala@...ux.intel.com> wrote:
> > > > > > > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> > > > > > > > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn
> > > > > > > > > > Voravootivat
> > > > > > > > > > wrote:
> > > > > > > > > > > The Lyude fde7266fb2f6 change is actually based on
> > > > > > > > > > > Chromium
> > > > > > > > > > > change
> > > > > > > > > > > (https://crrev.com/c/1650325) that fixes the brightness
> > > > > > > > > > > for
> > > > > > > > > > > Samsung
> > > > > > > > > > > Galaxy Chromebook. So currently we have 2 examples that
> > > > > > > > > > > use
> > > > > > > > > > > LSB
> > > > > > > > > > > interpretation and 1 that use MSB.
> > > > > > > > > >
> > > > > > > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register
> > > > > > > > > > represents
> > > > > > > > > > a
> > > > > > > > > > value
> > > > > > > > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT
> > > > > > > > > > bit
> > > > > > > > > > is cleared to 0, only the 8 MSB of the brightness control
> > > > > > > > > > value
> > > > > > > > > > can be
> > > > > > > > > > controlled.
> > > > > > > > > > (See Note below.)
> > > > > > > > > > Assigned bits are allocated to the MSB of the enabled
> > > > > > > > > > register
> > > > > > > > > > combination."
> > > > > > > > > >
> > > > > > > > > > I think that's pretty clear the assigned bits are supposed
> > > > > > > > > > to
> > > > > > > > > > be
> > > > > > > > > > msb aligned.
> > > > > > > > >
> > > > > > > > > I guess there's some email issues happening, but just to
> > > > > > > > > clarify:
> > > > > > > > >
> > > > > > > > > When the spec says MSB in caps here it clearly means
> > > > > > > > > "most significant-bit(s)" since otherwise "8 MSB" would not
> > > > > > > > > make
> > > > > > > > > any sense in the context of a 2 byte value.
> > > > > > > > >
> > > > > > > > > Granted the spec is crap here since "Table 1-1: Acronyms and
> > > > > > > > > Initialism" does claim "MSB" should be byte(s) and "msb"
> > > > > > > > > bit(s).
> > > > > > > > >
> > > > > > > > > Also I can't imagine anyone would allocate the bits starting
> > > > > > > > > from the lsb when the whole thing is clearly supposed to be a
> > > > > > > > > 16bit big endian integer. So with >8 assigned bits you'd end
> > > > > > > > > up with crazy stuff like this:
> > > > > > > > >
> > > > > > > > > [ 7 ... 0 ][7 ... 0]
> > > > > > > > > [ 8 MSB ][XXXX][N LSB]
> > > > > > > > >
> > > > > > > > > so you couldn't even treat the value as a regular big endian
> > > > > > > > > thing. Instead, if you squint a bit, it now looks like a funky
> > > > > > > > > little endian value. So we're deep into some mixed endian land
> > > > > > > > > where nothing makes sense anymore.
> > > > > > > > >
> > > > > > > > > Anyways I think the code should simply do this to match the
> > > > > > > > > spec:
> > > > > > > > > u16 value = brightness << (16 - num_assigned_bits);
> > > > > > > > > val[0] = value >> 8;
> > > > > > > > > val[1] = value & 0xff;
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <
> > > > > > > > > > > chowski@...omium.org> wrote:
> > > > > > > > > > > > Apologies for being too vague. To be as precise I can
> > > > > > > > > > > > be,
> > > > > > > > > > > > here
> > > > > > > > > > > > is the
> > > > > > > > > > > > specific code delta I tested:
> > > > > > > > > > > > https://crrev.com/c/2406616
> > > > > > > > > > > > . To
> > > > > > > > > > > > answer
> > > > > > > > > > > > your other question, the code I tested against is indeed
> > > > > > > > > > > > including the
> > > > > > > > > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my
> > > > > > > > > > > > commit
> > > > > > > > > > > > message): our current top-of-tree for our 5.4 branch
> > > > > > > > > > > > includes
> > > > > > > > > > > > the
> > > > > > > > > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll
> > > > > > > > > > > > note
> > > > > > > > > > > > that
> > > > > > > > > > > > change
> > > > > > > > > > > > is exactly the change which breaks my Pixelbook model:
> > > > > > > > > > > > prior
> > > > > > > > > > > > to the
> > > > > > > > > > > > change, the max_brightness was hard-coded to 0xFFFF and
> > > > > > > > > > > > the
> > > > > > > > > > > > math
> > > > > > > > > > > > worked out that it didn't matter that the hardware cared
> > > > > > > > > > > > about
> > > > > > > > > > > > the MSB
> > > > > > > > > > > > despite the driver code caring about the LSB.
> > > > > > > > > > > >
> > > > > > > > > > > > To answer Ville's question: the fde7266fb2f6 change
> > > > > > > > > > > > which
> > > > > > > > > > > > fixes one
> > > > > > > > > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some
> > > > > > > > > > > > bug
> > > > > > > > > > > > reports I
> > > > > > > > > > > > dug up) and breaks another (Pixelbook); so unfortunately
> > > > > > > > > > > > I
> > > > > > > > > > > > believe we
> > > > > > > > > > > > need a quirk at least for some laptop. Reading through
> > > > > > > > > > > > the
> > > > > > > > > > > > copy of the
> > > > > > > > > > > > datasheet I have, it wasn't clear to me which was the
> > > > > > > > > > > > correct
> > > > > > > > > > > > interpretation. I'm cc'ing puthik@, who was leaning
> > > > > > > > > > > > toward
> > > > > > > > > > > > the
> > > > > > > > > > > > current
> > > > > > > > > > > > kernel code (caring about LSB) being the correct
> > > > > > > > > > > > interpretation. I
> > > > > > > > > > > > believe we have other chromebooks which do rely on LSB
> > > > > > > > > > > > functionality,
> > > > > > > > > > > > so unless we can find more examples of laptops wanting
> > > > > > > > > > > > MSB
> > > > > > > > > > > > it
> > > > > > > > > > > > currently looks like Pixelbook is the outlier.
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > > > > > > > > > <jani.nikula@...ux.intel.com> wrote:
> > > > > > > > > > > > > On Thu, 17 Sep 2020, Kevin Chowski <
> > > > > > > > > > > > > chowski@...omium.org
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > We have observed that Google Pixelbook's backlight
> > > > > > > > > > > > > > hardware is
> > > > > > > > > > > > > > interpretting these backlight bits from the most-
> > > > > > > > > > > > > > significant side of the
> > > > > > > > > > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16),
> > > > > > > > > > > > > > whereas
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > driver code
> > > > > > > > > > > > > > assumes the peripheral cares about the least-
> > > > > > > > > > > > > > significant
> > > > > > > > > > > > > > bits.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Testing was done from within Chrome OS's build
> > > > > > > > > > > > > > environment
> > > > > > > > > > > > > > when the
> > > > > > > > > > > > > > patch is backported to 5.4 (the version we are newly
> > > > > > > > > > > > > > targeting for the
> > > > > > > > > > > > > > Pixelbook); for the record:
> > > > > > > > > > > > > > $ emerge-eve-kernelnext sys-kernel/chromeos-
> > > > > > > > > > > > > > kernel-
> > > > > > > > > > > > > > 5_4
> > > > > > > > > > > > > > && \
> > > > > > > > > > > > > > ./update_kernel.sh --remote=$IP
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on
> > > > > > > > > > > > > > my
> > > > > > > > > > > > > > laptop to verify
> > > > > > > > > > > > > > that the registers were being set according to what
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > actual hardware
> > > > > > > > > > > > > > expects; I also observe that the backlight is
> > > > > > > > > > > > > > noticeably
> > > > > > > > > > > > > > brighter with
> > > > > > > > > > > > > > this patch.
> > > > > > > > > > > > >
> > > > > > > > > > > > > It's unclear to me what kernel version this is
> > > > > > > > > > > > > against,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > what you've
> > > > > > > > > > > > > actually tested.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6
> > > > > > > > > > > > > ("drm/i915: Fix eDP
> > > > > > > > > > > > > DPCD aux max backlight calculations")?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I just want to make sure you've tested with all the
> > > > > > > > > > > > > relevant
> > > > > > > > > > > > > fixes
> > > > > > > > > > > > > before adding quirks.
> > > > > > > > > > > > >
> > > > > > > > > > > > > BR,
> > > > > > > > > > > > > Jani.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Kevin Chowski <chowski@...omium.org>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > > > > > > > > > > +++++++++++++++++++
> > > > > > > > > > > > > > drivers/gpu/drm/i915/display/intel_quirks.c | 13
> > > > > > > > > > > > > > +++++++
> > > > > > > > > > > > > > drivers/gpu/drm/i915/i915_drv.h | 1
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > 3 files changed, 48 insertions(+)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_dp_aux_backligh
> > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > c
> > > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backligh
> > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > c
> > > > > > > > > > > > > > index acbd7eb66cbe3..99c98f217356d 100644
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_dp_aux_backligh
> > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > c
> > > > > > > > > > > > > > +++
> > > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backligh
> > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > c
> > > > > > > > > > > > > > @@ -91,6 +91,23 @@ static u32
> > > > > > > > > > > > > > intel_dp_aux_get_backlight(struct intel_connector
> > > > > > > > > > > > > > *connector)
> > > > > > > > > > > > > > if (intel_dp->edp_dpcd[2] &
> > > > > > > > > > > > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > > > > > > > > > > level = (read_val[0] << 8 |
> > > > > > > > > > > > > > read_val[1]);
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > + if (i915->quirks &
> > > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > > > > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > > > > + &read_
> > > > > > > > > > > > > > va
> > > > > > > > > > > > > > l[0]
> > > > > > > > > > > > > > )) {
> > > > > > > > > > > > > > + DRM_DEBUG_KMS("Failed to read
> > > > > > > > > > > > > > DPCD
> > > > > > > > > > > > > > register 0x%x\n",
> > > > > > > > > > > > > > + DP_EDP_PWMGEN_
> > > > > > > > > > > > > > BI
> > > > > > > > > > > > > > T_CO
> > > > > > > > > > > > > > UNT);
> > > > > > > > > > > > > > + return 0;
> > > > > > > > > > > > > > + }
> > > > > > > > > > > > > > + // Only bits 4:0 are used, 7:5 are
> > > > > > > > > > > > > > reserved.
> > > > > > > > > > > > > > + read_val[0] = read_val[0] & 0x1F;
> > > > > > > > > > > > > > + if (read_val[0] > 16) {
> > > > > > > > > > > > > > + DRM_DEBUG_KMS("Invalid
> > > > > > > > > > > > > > DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most
> > > > > > > > > > > > > > 16\n",
> > > > > > > > > > > > > > + read_v
> > > > > > > > > > > > > > al
> > > > > > > > > > > > > > [0])
> > > > > > > > > > > > > > ;
> > > > > > > > > > > > > > + return 0;
> > > > > > > > > > > > > > + }
> > > > > > > > > > > > > > + level >>= 16 - read_val[0];
> > > > > > > > > > > > > > + }
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > return level;
> > > > > > > > > > > > > > }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > @@ -106,6 +123,23 @@
> > > > > > > > > > > > > > intel_dp_aux_set_backlight(const
> > > > > > > > > > > > > > struct drm_connector_state *conn_state, u32 lev
> > > > > > > > > > > > > > struct drm_i915_private *i915 =
> > > > > > > > > > > > > > dp_to_i915(intel_dp);
> > > > > > > > > > > > > > u8 vals[2] = { 0x0 };
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > + if (i915->quirks &
> > > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > > > > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > > > > + &vals[
> > > > > > > > > > > > > > 0]
> > > > > > > > > > > > > > )) {
> > > > > > > > > > > > > > + DRM_DEBUG_KMS("Failed to write
> > > > > > > > > > > > > > aux
> > > > > > > > > > > > > > backlight level: Failed to read DPCD register
> > > > > > > > > > > > > > 0x%x\n",
> > > > > > > > > > > > > > + DP_EDP_PWMGE
> > > > > > > > > > > > > > N_
> > > > > > > > > > > > > > BIT_
> > > > > > > > > > > > > > COUNT);
> > > > > > > > > > > > > > + return;
> > > > > > > > > > > > > > + }
> > > > > > > > > > > > > > + // Only bits 4:0 are used, 7:5 are
> > > > > > > > > > > > > > reserved.
> > > > > > > > > > > > > > + vals[0] = vals[0] & 0x1F;
> > > > > > > > > > > > > > + if (vals[0] > 16) {
> > > > > > > > > > > > > > + DRM_DEBUG_KMS("Failed to write
> > > > > > > > > > > > > > aux
> > > > > > > > > > > > > > backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT
> > > > > > > > > > > > > > 0x%X,
> > > > > > > > > > > > > > expected at most 16\n",
> > > > > > > > > > > > > > + vals[0
> > > > > > > > > > > > > > ])
> > > > > > > > > > > > > > ;
> > > > > > > > > > > > > > + return;
> > > > > > > > > > > > > > + }
> > > > > > > > > > > > > > + level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > > > > > > > > > + }
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > vals[0] = level;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > /* Write the MSB and/or LSB */
> > > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > @@ -53,6 +53,16 @@ static void
> > > > > > > > > > > > > > quirk_increase_ddi_disabled_time(struct
> > > > > > > > > > > > > > drm_i915_private
> > > > > > > > > > > > > > *i915)
> > > > > > > > > > > > > > drm_info(&i915->drm, "Applying Increase DDI
> > > > > > > > > > > > > > Disabled
> > > > > > > > > > > > > > quirk\n");
> > > > > > > > > > > > > > }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > +/*
> > > > > > > > > > > > > > + * Some eDP backlight hardware uses the most-
> > > > > > > > > > > > > > significant
> > > > > > > > > > > > > > bits of the brightness
> > > > > > > > > > > > > > + * register, so brightness values must be shifted
> > > > > > > > > > > > > > first.
> > > > > > > > > > > > > > + */
> > > > > > > > > > > > > > +static void
> > > > > > > > > > > > > > quirk_shift_edp_backlight_brightness(struct
> > > > > > > > > > > > > > drm_i915_private *i915)
> > > > > > > > > > > > > > +{
> > > > > > > > > > > > > > + i915->quirks |=
> > > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > > > > > > > > > + DRM_INFO("Applying shift eDP backlight
> > > > > > > > > > > > > > brightness
> > > > > > > > > > > > > > quirk\n");
> > > > > > > > > > > > > > +}
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > struct intel_quirk {
> > > > > > > > > > > > > > int device;
> > > > > > > > > > > > > > int subsystem_vendor;
> > > > > > > > > > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk
> > > > > > > > > > > > > > intel_quirks[] = {
> > > > > > > > > > > > > > /* ASRock ITX*/
> > > > > > > > > > > > > > { 0x3185, 0x1849, 0x2212,
> > > > > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > > > > { 0x3184, 0x1849, 0x2212,
> > > > > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + /* Google Pixelbook */
> > > > > > > > > > > > > > + { 0x591E, 0x8086, 0x2212,
> > > > > > > > > > > > > > quirk_shift_edp_backlight_brightness },
> > > > > > > > > > > > > > };
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > void intel_init_quirks(struct drm_i915_private
> > > > > > > > > > > > > > *i915)
> > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > > > > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > > > > > > > > > > #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > > > > > > > > > > #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > > > > > > > > > > #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > > > > > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > struct intel_fbdev;
> > > > > > > > > > > > > > struct intel_fbc_work;
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Jani Nikula, Intel Open Source Graphics Center
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Ville Syrjälä
> > > > > > > > > > Intel
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Intel-gfx mailing list
> > > > > > > > > > Intel-gfx@...ts.freedesktop.org
> > > > > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Ville Syrjälä
> > > > > > > > > Intel
> > > > --
> > > > Cheers,
> > > > Lyude Paul (she/her)
> > > > Software Engineer at Red Hat
> > > >
> > --
> > Cheers,
> > Lyude Paul (she/her)
> > Software Engineer at Red Hat
> >
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Powered by blists - more mailing lists