Re: [PATCH v2 3/3] arm64: dts: qcom: trogdor: Add brightness-levels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 14, 2020 at 06:51:19AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Wed, Oct 14, 2020 at 4:33 AM Daniel Thompson
> <daniel.thompson@xxxxxxxxxx> wrote:
> >
> > On Tue, Oct 13, 2020 at 09:28:38AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Tue, Oct 13, 2020 at 1:01 AM Alexandru Stan <amstan@xxxxxxxxxxxx> wrote:
> > > >
> > > > Now that we have better interpolation for the backlight
> > > > ("backlight: pwm_bl: Fix interpolation"), we can now add the curve to
> > > > the trogdor boards, being careful to crop the low end.
> > >
> > > Just to make it clear, the patch this depends on hasn't landed yet.
> > > Presumably it will land in the v5.10 timeframe?  That means that
> > > without extra coordination this patch can target v5.11.
> >
> > You're talking about patch 1 from this set? Despite the title I view
> > the patch as changing policy (albeit one that does also fix some annoying
> > quantization errors at the same time) so it's not necessarily a
> > candidate for merging outside the merge window (I've not checked with
> > Lee but I think it likely the shutter is already down for features).
> 
> Ugh, I'm off by one.  :(  Right.  New features prepared for v5.10
> should already have been baking in linuxnext and merge requests have
> already started flowing towards Linus.  After v5.10-rc1 then it'd just
> fixes and this doesn't really qualify.  So the timing dictates that
> patch #1 will land in v5.11, not v5.10.
> 
> 
> > Moreover I'm not clear why there a dependency here that would stop the
> > changes landing in different trees.
> 
> I haven't tried Alexandru's device tree patch without the associated
> code changes, but I guess I just assumed that it would make a really
> ugly (non)ideal backlight curve and we'd be better off with what we
> currently have (AKA no curve specified at all).
> 
> Hrm, thinking about it, I guess the worst case is a slightly non-ideal
> backlight curve and it would be all good in the final v5.11 which
> would have the device tree and code changes, so you're right that both
> the code and device tree could target v5.11 without anything too
> bad...

Excellent. I'll try to remember this for v3 so I can get my Acked-by
versus Reviewed-by tags correct ;-) .


Daniel.


> 
> 
> > Daniel.
> >
> >
> > > > Signed-off-by: Alexandru Stan <amstan@xxxxxxxxxxxx>
> > > > ---
> > > >
> > > >  arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 9 +++++++++
> > > >  1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> > > > index bf875589d364..ccdabc6c4994 100644
> > > > --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> > > > @@ -179,6 +179,15 @@ pp3300_fp_tp: pp3300-fp-tp-regulator {
> > > >         backlight: backlight {
> > > >                 compatible = "pwm-backlight";
> > > >
> > > > +               /* The panels don't seem to like anything below ~ 5% */
> > > > +               brightness-levels = <
> > > > +                       196 256 324 400 484 576 676 784 900 1024 1156 1296
> > > > +                       1444 1600 1764 1936 2116 2304 2500 2704 2916 3136
> > > > +                       3364 3600 3844 4096
> > > > +               >;
> > > > +               num-interpolated-steps = <64>;
> > > > +               default-brightness-level = <951>;
> > >
> > > I haven't done lots of digging here, but this matches what Alexandru
> > > and Matthias agreed upon for the downstream tree and seems sane.
> > > Thus:
> > >
> > > Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux