linux-kernel - Re: [PATCH 2/3] drm/komeda: Add drm_ctm_to

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20191009151024.GF16989@phenom.ffwll.local>
Date:   Wed, 9 Oct 2019 17:10:24 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Ilia Mirkin <imirkin@...m.mit.edu>
Cc:     Brian Starkey <Brian.Starkey@....com>, nd <nd@....com>,
        "Oscar Zhang (Arm Technology China)" <Oscar.Zhang@....com>,
        "Tiannan Zhu (Arm Technology China)" <Tiannan.Zhu@....com>,
        Mihail Atanassov <Mihail.Atanassov@....com>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "Jonathan Chai (Arm Technology China)" <Jonathan.Chai@....com>,
        Liviu Dudau <Liviu.Dudau@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "Julien Yin (Arm Technology China)" <Julien.Yin@....com>,
        "Channing Chen (Arm Technology China)" <Channing.Chen@....com>,
        "james qian wang (Arm Technology China)" <james.qian.wang@....com>,
        "Yiqi Kang (Arm Technology China)" <Yiqi.Kang@....com>,
        Ben Davis <Ben.Davis@....com>,
        "Thomas Sun (Arm Technology China)" <thomas.Sun@....com>,
        Ayan Halder <Ayan.Halder@....com>,
        "sean@...rly.run" <sean@...rly.run>,
        "Lowry Li (Arm Technology China)" <Lowry.Li@....com>
Subject: Re: [PATCH 2/3] drm/komeda: Add drm_ctm_to_coeffs()

On Mon, Sep 30, 2019 at 07:56:13AM -0400, Ilia Mirkin wrote:
> On Mon, Sep 30, 2019 at 7:05 AM Brian Starkey <Brian.Starkey@....com> wrote:
> >
> > Hi James,
> >
> > On Mon, Sep 30, 2019 at 04:54:41AM +0000, james qian wang (Arm Technology China) wrote:
> > > This function is used to convert drm_color_ctm S31.32 sign-magnitude
> > > value to komeda required Q2.12 2's complement
> > >
> > > Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@....com>
> > > ---
> > >  .../arm/display/komeda/komeda_color_mgmt.c    | 27 +++++++++++++++++++
> > >  .../arm/display/komeda/komeda_color_mgmt.h    |  1 +
> > >  2 files changed, 28 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> > > index c180ce70c26c..c92c82eebddb 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> > > @@ -117,3 +117,30 @@ void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs)
> > >  {
> > >       drm_lut_to_coeffs(lut_blob, coeffs, sector_tbl, ARRAY_SIZE(sector_tbl));
> > >  }
> > > +
> > > +/* Convert from S31.32 sign-magnitude to HW Q2.12 2's complement */
> > > +static s32 drm_ctm_s31_32_to_q2_12(u64 input)
> > > +{
> > > +     u64 mag = (input & ~BIT_ULL(63)) >> 20;
> > > +     bool negative = !!(input & BIT_ULL(63));
> > > +     u32 val;
> > > +
> > > +     /* the range of signed 2s complement is [-2^n, 2^n - 1] */
> > > +     val = clamp_val(mag, 0, negative ? BIT(14) : BIT(14) - 1);
> > > +
> > > +     return negative ? 0 - val : val;
> > > +}
> >
> > This function looks generally useful. Should it be in DRM core
> > (assuming there isn't already one there)?
> >
> > You can use a parameter to determine the number of bits desired in the
> > output.
> 
> I suspect every driver needs to do something similar. You can see what
> I did for nouveau here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88b703527ba70659365d989f29579f1292ebf9c3
> 
> (look for csc_drm_to_base)
> 
> Would be great to have a common helper which correctly accounts for
> all the variability.

Yeah the sign-bit 31.32 fixed point format is probably the most ludicrous
uapi fumble we've ever done. A shared function, rolled out to drivers, to
switch it to a signed 2 complements integer sounds like a _very_ good
idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch