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>
