diff mbox

drm/i915: intel_backlight scale() math WA v2

Message ID 1411574099-21977-1-git-send-email-joe.konno@linux.intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Joe Konno Sept. 24, 2014, 3:54 p.m. UTC
From: Joe Konno <joe.konno@intel.com>

Improper truncated integer division in the scale() function causes
actual_brightness != brightness. This (partial) work-around should be
sufficient for a majority of use-cases, but it is by no means a complete
solution.

TODO: Determine how best to scale "user" values to "hw" values, and
vice-versa, when the ranges are of different sizes. That would be a
buggy scenario even with this work-around.

The issue was introduced in the following (v3.17-rc1) commit:

    6dda730 drm/i915: respect the VBT minimum backlight brightness

v2: (thanks to Chris Wilson) clarify commit message, use rounded division
macro

Signed-off-by: Joe Konno <joe.konno@intel.com>
---
 drivers/gpu/drm/i915/intel_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Hans de Goede Sept. 24, 2014, 4:06 p.m. UTC | #1
Hi,

On 09/24/2014 05:54 PM, Joe Konno wrote:
> From: Joe Konno <joe.konno@intel.com>
> 
> Improper truncated integer division in the scale() function causes
> actual_brightness != brightness. This (partial) work-around should be
> sufficient for a majority of use-cases, but it is by no means a complete
> solution.
> 
> TODO: Determine how best to scale "user" values to "hw" values, and
> vice-versa, when the ranges are of different sizes. That would be a
> buggy scenario even with this work-around.
> 
> The issue was introduced in the following (v3.17-rc1) commit:
> 
>     6dda730 drm/i915: respect the VBT minimum backlight brightness
> 
> v2: (thanks to Chris Wilson) clarify commit message, use rounded division
> macro

I wonder why do scaling at all, why not simply shift hw_min - hw_max range
to 0 - (hw_max - hw_min) range and set max_brightness as seen by userspace
to (hw_max - hw_min) ?

Regards,

Hans


> 
> Signed-off-by: Joe Konno <joe.konno@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> index f17ada3..dcdfbb3 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
>  	/* avoid overflows */
>  	target_val = (uint64_t)(source_val - source_min) *
>  		(target_max - target_min);
> -	do_div(target_val, source_max - source_min);
> +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
>  	target_val += target_min;
>  
>  	return target_val;
>
Jani Nikula Sept. 24, 2014, 5:07 p.m. UTC | #2
On Wed, 24 Sep 2014, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 09/24/2014 05:54 PM, Joe Konno wrote:
>> From: Joe Konno <joe.konno@intel.com>
>> 
>> Improper truncated integer division in the scale() function causes
>> actual_brightness != brightness. This (partial) work-around should be
>> sufficient for a majority of use-cases, but it is by no means a complete
>> solution.
>> 
>> TODO: Determine how best to scale "user" values to "hw" values, and
>> vice-versa, when the ranges are of different sizes. That would be a
>> buggy scenario even with this work-around.
>> 
>> The issue was introduced in the following (v3.17-rc1) commit:
>> 
>>     6dda730 drm/i915: respect the VBT minimum backlight brightness
>> 
>> v2: (thanks to Chris Wilson) clarify commit message, use rounded division
>> macro
>
> I wonder why do scaling at all, why not simply shift hw_min - hw_max range
> to 0 - (hw_max - hw_min) range and set max_brightness as seen by userspace
> to (hw_max - hw_min) ?

Mostly in preparation for a future where we expose an arbitrary range,
say 0..100 or 0..255 to the userspace.

BR,
Jani.


>
> Regards,
>
> Hans
>
>
>> 
>> Signed-off-by: Joe Konno <joe.konno@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_panel.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
>> index f17ada3..dcdfbb3 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
>>  	/* avoid overflows */
>>  	target_val = (uint64_t)(source_val - source_min) *
>>  		(target_max - target_min);
>> -	do_div(target_val, source_max - source_min);
>> +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
>>  	target_val += target_min;
>>  
>>  	return target_val;
>> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
U. Artie Eoff Sept. 24, 2014, 5:41 p.m. UTC | #3
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Jani Nikula
> Sent: Wednesday, September 24, 2014 10:08 AM
> To: Hans de Goede; Joe Konno; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
> 
> On Wed, 24 Sep 2014, Hans de Goede <hdegoede@redhat.com> wrote:
> > Hi,
> >
> > On 09/24/2014 05:54 PM, Joe Konno wrote:
> >> From: Joe Konno <joe.konno@intel.com>
> >>
> >> Improper truncated integer division in the scale() function causes
> >> actual_brightness != brightness. This (partial) work-around should be
> >> sufficient for a majority of use-cases, but it is by no means a complete
> >> solution.
> >>
> >> TODO: Determine how best to scale "user" values to "hw" values, and
> >> vice-versa, when the ranges are of different sizes. That would be a
> >> buggy scenario even with this work-around.
> >>
> >> The issue was introduced in the following (v3.17-rc1) commit:
> >>
> >>     6dda730 drm/i915: respect the VBT minimum backlight brightness
> >>
> >> v2: (thanks to Chris Wilson) clarify commit message, use rounded division
> >> macro
> >
> > I wonder why do scaling at all, why not simply shift hw_min - hw_max range
> > to 0 - (hw_max - hw_min) range and set max_brightness as seen by userspace
> > to (hw_max - hw_min) ?
> 
> Mostly in preparation for a future where we expose an arbitrary range,
> say 0..100 or 0..255 to the userspace.
> 

The problem with this scaling method is that scaling from user level to hw level and
back to user level is ambiguous since there isn't a 1:1 mapping between the user
range and the hw range.

On the other hand, this patch does fix a bug in the currently used method (scaling).
That, at least, is an improvement nonetheless.

U. Artie

> BR,
> Jani.
> 
> 
> >
> > Regards,
> >
> > Hans
> >
> >
> >>
> >> Signed-off-by: Joe Konno <joe.konno@intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> >> index f17ada3..dcdfbb3 100644
> >> --- a/drivers/gpu/drm/i915/intel_panel.c
> >> +++ b/drivers/gpu/drm/i915/intel_panel.c
> >> @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
> >>  	/* avoid overflows */
> >>  	target_val = (uint64_t)(source_val - source_min) *
> >>  		(target_max - target_min);
> >> -	do_div(target_val, source_max - source_min);
> >> +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
> >>  	target_val += target_min;
> >>
> >>  	return target_val;
> >>
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Jani Nikula, Intel Open Source Technology Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
U. Artie Eoff Sept. 26, 2014, 5:15 p.m. UTC | #4
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Joe Konno
> Sent: Wednesday, September 24, 2014 8:55 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
> 
> From: Joe Konno <joe.konno@intel.com>
> 
> Improper truncated integer division in the scale() function causes
> actual_brightness != brightness. This (partial) work-around should be
> sufficient for a majority of use-cases, but it is by no means a complete
> solution.
> 
> TODO: Determine how best to scale "user" values to "hw" values, and
> vice-versa, when the ranges are of different sizes. That would be a
> buggy scenario even with this work-around.
> 
> The issue was introduced in the following (v3.17-rc1) commit:
> 
>     6dda730 drm/i915: respect the VBT minimum backlight brightness
> 
> v2: (thanks to Chris Wilson) clarify commit message, use rounded division
> macro
> 

Reviewed-by: U. Artie Eoff <ullysses.a.eoff@intel.com>

> Signed-off-by: Joe Konno <joe.konno@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> index f17ada3..dcdfbb3 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
>  	/* avoid overflows */
>  	target_val = (uint64_t)(source_val - source_min) *
>  		(target_max - target_min);
> -	do_div(target_val, source_max - source_min);
> +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
>  	target_val += target_min;
> 
>  	return target_val;
> --
> 2.1.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Jani Nikula Sept. 29, 2014, 1:07 p.m. UTC | #5
On Wed, 24 Sep 2014, Joe Konno <joe.konno@linux.intel.com> wrote:
> From: Joe Konno <joe.konno@intel.com>
>
> Improper truncated integer division in the scale() function causes
> actual_brightness != brightness. This (partial) work-around should be
> sufficient for a majority of use-cases, but it is by no means a complete
> solution.
>
> TODO: Determine how best to scale "user" values to "hw" values, and
> vice-versa, when the ranges are of different sizes. That would be a
> buggy scenario even with this work-around.
>
> The issue was introduced in the following (v3.17-rc1) commit:
>
>     6dda730 drm/i915: respect the VBT minimum backlight brightness
>
> v2: (thanks to Chris Wilson) clarify commit message, use rounded division
> macro
>
> Signed-off-by: Joe Konno <joe.konno@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> index f17ada3..dcdfbb3 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
>  	/* avoid overflows */
>  	target_val = (uint64_t)(source_val - source_min) *
>  		(target_max - target_min);
> -	do_div(target_val, source_max - source_min);
> +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);

This fails to build with CONFIG_X86_32=y:

drivers/built-in.o: In function `scale':
intel_panel.c:(.text+0x12ab38): undefined reference to `__udivdi3'
make: *** [vmlinux] Error 1


BR,
Jani.


>  	target_val += target_min;
>  
>  	return target_val;
> -- 
> 2.1.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
U. Artie Eoff Sept. 29, 2014, 5:50 p.m. UTC | #6
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Jani Nikula
> Sent: Monday, September 29, 2014 6:07 AM
> To: Joe Konno; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
> 
> On Wed, 24 Sep 2014, Joe Konno <joe.konno@linux.intel.com> wrote:
> > From: Joe Konno <joe.konno@intel.com>
> >
> > Improper truncated integer division in the scale() function causes
> > actual_brightness != brightness. This (partial) work-around should be
> > sufficient for a majority of use-cases, but it is by no means a complete
> > solution.
> >
> > TODO: Determine how best to scale "user" values to "hw" values, and
> > vice-versa, when the ranges are of different sizes. That would be a
> > buggy scenario even with this work-around.
> >
> > The issue was introduced in the following (v3.17-rc1) commit:
> >
> >     6dda730 drm/i915: respect the VBT minimum backlight brightness
> >
> > v2: (thanks to Chris Wilson) clarify commit message, use rounded division
> > macro
> >
> > Signed-off-by: Joe Konno <joe.konno@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> > index f17ada3..dcdfbb3 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
> >  	/* avoid overflows */
> >  	target_val = (uint64_t)(source_val - source_min) *
> >  		(target_max - target_min);
> > -	do_div(target_val, source_max - source_min);
> > +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
> 
> This fails to build with CONFIG_X86_32=y:
> 
> drivers/built-in.o: In function `scale':
> intel_panel.c:(.text+0x12ab38): undefined reference to `__udivdi3'
> make: *** [vmlinux] Error 1
> 
> 

Do you have a recommended workaround?  Should we just
use the v1 technique instead?

U. Artie

> BR,
> Jani.
> 
> 
> >  	target_val += target_min;
> >
> >  	return target_val;
> > --
> > 2.1.0
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Jani Nikula, Intel Open Source Technology Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Chris Wilson Sept. 29, 2014, 6:46 p.m. UTC | #7
On Mon, Sep 29, 2014 at 05:50:57PM +0000, Eoff, Ullysses A wrote:
> > -----Original Message-----
> > From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Jani Nikula
> > Sent: Monday, September 29, 2014 6:07 AM
> > To: Joe Konno; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
> > 
> > On Wed, 24 Sep 2014, Joe Konno <joe.konno@linux.intel.com> wrote:
> > > From: Joe Konno <joe.konno@intel.com>
> > >
> > > Improper truncated integer division in the scale() function causes
> > > actual_brightness != brightness. This (partial) work-around should be
> > > sufficient for a majority of use-cases, but it is by no means a complete
> > > solution.
> > >
> > > TODO: Determine how best to scale "user" values to "hw" values, and
> > > vice-versa, when the ranges are of different sizes. That would be a
> > > buggy scenario even with this work-around.
> > >
> > > The issue was introduced in the following (v3.17-rc1) commit:
> > >
> > >     6dda730 drm/i915: respect the VBT minimum backlight brightness
> > >
> > > v2: (thanks to Chris Wilson) clarify commit message, use rounded division
> > > macro
> > >
> > > Signed-off-by: Joe Konno <joe.konno@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> > > index f17ada3..dcdfbb3 100644
> > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
> > >  	/* avoid overflows */
> > >  	target_val = (uint64_t)(source_val - source_min) *
> > >  		(target_max - target_min);
> > > -	do_div(target_val, source_max - source_min);
> > > +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
> > 
> > This fails to build with CONFIG_X86_32=y:
> > 
> > drivers/built-in.o: In function `scale':
> > intel_panel.c:(.text+0x12ab38): undefined reference to `__udivdi3'
> > make: *** [vmlinux] Error 1
> > 
> > 
> 
> Do you have a recommended workaround?  Should we just
> use the v1 technique instead?

Compromise and write DIV_ROUND_CLOSEST_ULL(). :|
-Chris
Lespiau, Damien Sept. 29, 2014, 7:31 p.m. UTC | #8
On Mon, Sep 29, 2014 at 05:50:57PM +0000, Eoff, Ullysses A wrote:
> > -----Original Message-----
> > From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Jani Nikula
> > Sent: Monday, September 29, 2014 6:07 AM
> > To: Joe Konno; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
> > 
> > On Wed, 24 Sep 2014, Joe Konno <joe.konno@linux.intel.com> wrote:
> > > From: Joe Konno <joe.konno@intel.com>
> > >
> > > Improper truncated integer division in the scale() function causes
> > > actual_brightness != brightness. This (partial) work-around should be
> > > sufficient for a majority of use-cases, but it is by no means a complete
> > > solution.
> > >
> > > TODO: Determine how best to scale "user" values to "hw" values, and
> > > vice-versa, when the ranges are of different sizes. That would be a
> > > buggy scenario even with this work-around.
> > >
> > > The issue was introduced in the following (v3.17-rc1) commit:
> > >
> > >     6dda730 drm/i915: respect the VBT minimum backlight brightness
> > >
> > > v2: (thanks to Chris Wilson) clarify commit message, use rounded division
> > > macro
> > >
> > > Signed-off-by: Joe Konno <joe.konno@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> > > index f17ada3..dcdfbb3 100644
> > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
> > >  	/* avoid overflows */
> > >  	target_val = (uint64_t)(source_val - source_min) *
> > >  		(target_max - target_min);
> > > -	do_div(target_val, source_max - source_min);
> > > +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
> > 
> > This fails to build with CONFIG_X86_32=y:
> > 
> > drivers/built-in.o: In function `scale':
> > intel_panel.c:(.text+0x12ab38): undefined reference to `__udivdi3'
> > make: *** [vmlinux] Error 1
> > 
> > 
> 
> Do you have a recommended workaround?  Should we just
> use the v1 technique instead?

The problem is target_val is 64 bits and we're trying to do a 64 bits
division with the 32bits instruction set. That is usually handled by
__udivdi3 in libgcc (in userspace). We already have a
DIV_ROUND_CLOSEST_ULL() that uses do_div() in intel_display.c.
U. Artie Eoff Sept. 29, 2014, 8:34 p.m. UTC | #9
On Mon, 2014-09-29 at 20:31 +0100, Damien Lespiau wrote:
> On Mon, Sep 29, 2014 at 05:50:57PM +0000, Eoff, Ullysses A wrote:
> > > -----Original Message-----
> > > From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Jani Nikula
> > > Sent: Monday, September 29, 2014 6:07 AM
> > > To: Joe Konno; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
> > > 
> > > On Wed, 24 Sep 2014, Joe Konno <joe.konno@linux.intel.com> wrote:
> > > > From: Joe Konno <joe.konno@intel.com>
> > > >
> > > > Improper truncated integer division in the scale() function causes
> > > > actual_brightness != brightness. This (partial) work-around should be
> > > > sufficient for a majority of use-cases, but it is by no means a complete
> > > > solution.
> > > >
> > > > TODO: Determine how best to scale "user" values to "hw" values, and
> > > > vice-versa, when the ranges are of different sizes. That would be a
> > > > buggy scenario even with this work-around.
> > > >
> > > > The issue was introduced in the following (v3.17-rc1) commit:
> > > >
> > > >     6dda730 drm/i915: respect the VBT minimum backlight brightness
> > > >
> > > > v2: (thanks to Chris Wilson) clarify commit message, use rounded division
> > > > macro
> > > >
> > > > Signed-off-by: Joe Konno <joe.konno@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> > > > index f17ada3..dcdfbb3 100644
> > > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > > @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
> > > >  	/* avoid overflows */
> > > >  	target_val = (uint64_t)(source_val - source_min) *
> > > >  		(target_max - target_min);
> > > > -	do_div(target_val, source_max - source_min);
> > > > +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
> > > 
> > > This fails to build with CONFIG_X86_32=y:
> > > 
> > > drivers/built-in.o: In function `scale':
> > > intel_panel.c:(.text+0x12ab38): undefined reference to `__udivdi3'
> > > make: *** [vmlinux] Error 1
> > > 
> > > 
> > 
> > Do you have a recommended workaround?  Should we just
> > use the v1 technique instead?
> 
> The problem is target_val is 64 bits and we're trying to do a 64 bits
> division with the 32bits instruction set. That is usually handled by
> __udivdi3 in libgcc (in userspace). We already have a
> DIV_ROUND_CLOSEST_ULL() that uses do_div() in intel_display.c.
> 

Ok, DIV_ROUND_CLOSEST_ULL() would be the one we want I take it.  Would
intel_drv.h be the appropriate header to move DIV_ROUND_CLOSEST_ULL()
into so that we can use it in intel_panel.c, too?

U. Artie
U. Artie Eoff Nov. 8, 2014, 5:03 p.m. UTC | #10
On 09/24/2014 10:42 AM, Eoff, Ullysses A wrote:
>> -----Original Message-----
>> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Jani Nikula
>> Sent: Wednesday, September 24, 2014 10:08 AM
>> To: Hans de Goede; Joe Konno; intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
>>
>> On Wed, 24 Sep 2014, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 09/24/2014 05:54 PM, Joe Konno wrote:
>>>> From: Joe Konno <joe.konno@intel.com>
>>>>
>>>> Improper truncated integer division in the scale() function causes
>>>> actual_brightness != brightness. This (partial) work-around should be
>>>> sufficient for a majority of use-cases, but it is by no means a complete
>>>> solution.
>>>>
>>>> TODO: Determine how best to scale "user" values to "hw" values, and
>>>> vice-versa, when the ranges are of different sizes. That would be a
>>>> buggy scenario even with this work-around.
>>>>
>>>> The issue was introduced in the following (v3.17-rc1) commit:
>>>>
>>>>     6dda730 drm/i915: respect the VBT minimum backlight brightness
>>>>
>>>> v2: (thanks to Chris Wilson) clarify commit message, use rounded division
>>>> macro
>>> I wonder why do scaling at all, why not simply shift hw_min - hw_max range
>>> to 0 - (hw_max - hw_min) range and set max_brightness as seen by userspace
>>> to (hw_max - hw_min) ?
>> Mostly in preparation for a future where we expose an arbitrary range,
>> say 0..100 or 0..255 to the userspace.
>>
> The problem with this scaling method is that scaling from user level to hw level and
> back to user level is ambiguous since there isn't a 1:1 mapping between the user
> range and the hw range.
>
> On the other hand, this patch does fix a bug in the currently used method (scaling).
> That, at least, is an improvement nonetheless.
>
> U. Artie
Apologies for resurrecting an old thread.  But I think we still need to
address
this issue about not having a 1:1 mapping between user and hw levels.

Right now, the problem is that the user range is larger than the hw
range which
results in one or more user levels mapping to the same hw level.  And when
userspace requests one of those levels, the result that is reported back to
userspace might not be the same as what was requested.  Take for example, on
my system the hw range is [398, 7812] and the user range is [0, 7812]. 
Suppose
userspace requests level 7017.  This maps to hw level 7058.  And when
userspace requests the current level, 7018 is reported back (+1 from what
was originally requested).  In fact, with these particular ranges, there
are exactly
398 values that this occurs.

This problem will be compounded the larger the difference in length of the
discrete ranges; so long as user range > hw range.

Hans' solution would fix this problem, giving 1:1 mapping from hw to user
levels.

Jani's [future] solution would work too, since exposing a smaller range to
userspace than the hw range would isolate the non 1:1 mapping inside the
driver.

U. Artie
>> BR,
>> Jani.
>>
>>
>>> Regards,
>>>
>>> Hans
>>>
>>>
>>>> Signed-off-by: Joe Konno <joe.konno@intel.com>
>>>> ---
>>>>  drivers/gpu/drm/i915/intel_panel.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
>>>> index f17ada3..dcdfbb3 100644
>>>> --- a/drivers/gpu/drm/i915/intel_panel.c
>>>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>>>> @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
>>>>  	/* avoid overflows */
>>>>  	target_val = (uint64_t)(source_val - source_min) *
>>>>  		(target_max - target_min);
>>>> -	do_div(target_val, source_max - source_min);
>>>> +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
>>>>  	target_val += target_min;
>>>>
>>>>  	return target_val;
>>>>
>>> _______________________________________________
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> --
>> Jani Nikula, Intel Open Source Technology Center
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
Jani Nikula Nov. 10, 2014, 11:16 a.m. UTC | #11
On Sat, 08 Nov 2014, "Eoff, Ullysses A" <ullysses.a.eoff@intel.com> wrote:
> On 09/24/2014 10:42 AM, Eoff, Ullysses A wrote:
>>> -----Original Message-----
>>> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Jani Nikula
>>> Sent: Wednesday, September 24, 2014 10:08 AM
>>> To: Hans de Goede; Joe Konno; intel-gfx@lists.freedesktop.org
>>> Subject: Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
>>>
>>> On Wed, 24 Sep 2014, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 09/24/2014 05:54 PM, Joe Konno wrote:
>>>>> From: Joe Konno <joe.konno@intel.com>
>>>>>
>>>>> Improper truncated integer division in the scale() function causes
>>>>> actual_brightness != brightness. This (partial) work-around should be
>>>>> sufficient for a majority of use-cases, but it is by no means a complete
>>>>> solution.
>>>>>
>>>>> TODO: Determine how best to scale "user" values to "hw" values, and
>>>>> vice-versa, when the ranges are of different sizes. That would be a
>>>>> buggy scenario even with this work-around.
>>>>>
>>>>> The issue was introduced in the following (v3.17-rc1) commit:
>>>>>
>>>>>     6dda730 drm/i915: respect the VBT minimum backlight brightness
>>>>>
>>>>> v2: (thanks to Chris Wilson) clarify commit message, use rounded division
>>>>> macro
>>>> I wonder why do scaling at all, why not simply shift hw_min - hw_max range
>>>> to 0 - (hw_max - hw_min) range and set max_brightness as seen by userspace
>>>> to (hw_max - hw_min) ?
>>> Mostly in preparation for a future where we expose an arbitrary range,
>>> say 0..100 or 0..255 to the userspace.
>>>
>> The problem with this scaling method is that scaling from user level to hw level and
>> back to user level is ambiguous since there isn't a 1:1 mapping between the user
>> range and the hw range.
>>
>> On the other hand, this patch does fix a bug in the currently used method (scaling).
>> That, at least, is an improvement nonetheless.
>>
>> U. Artie
> Apologies for resurrecting an old thread.  But I think we still need to
> address
> this issue about not having a 1:1 mapping between user and hw levels.
>
> Right now, the problem is that the user range is larger than the hw
> range which
> results in one or more user levels mapping to the same hw level.  And when
> userspace requests one of those levels, the result that is reported back to
> userspace might not be the same as what was requested.  Take for example, on
> my system the hw range is [398, 7812] and the user range is [0, 7812]. 
> Suppose
> userspace requests level 7017.  This maps to hw level 7058.  And when
> userspace requests the current level, 7018 is reported back (+1 from what
> was originally requested).  In fact, with these particular ranges, there
> are exactly
> 398 values that this occurs.
>
> This problem will be compounded the larger the difference in length of the
> discrete ranges; so long as user range > hw range.
>
> Hans' solution would fix this problem, giving 1:1 mapping from hw to user
> levels.
>
> Jani's [future] solution would work too, since exposing a smaller range to
> userspace than the hw range would isolate the non 1:1 mapping inside the
> driver.

I think we should just pick an arbitrary range, say 0..100, and be done
with it. It's not like you'd be able to get much more than 100 distinct
brightness levels out of the backlight anyway, no matter what the PWM
settings.

BR,
Jani.




>
> U. Artie
>>> BR,
>>> Jani.
>>>
>>>
>>>> Regards,
>>>>
>>>> Hans
>>>>
>>>>
>>>>> Signed-off-by: Joe Konno <joe.konno@intel.com>
>>>>> ---
>>>>>  drivers/gpu/drm/i915/intel_panel.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
>>>>> index f17ada3..dcdfbb3 100644
>>>>> --- a/drivers/gpu/drm/i915/intel_panel.c
>>>>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>>>>> @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val,
>>>>>  	/* avoid overflows */
>>>>>  	target_val = (uint64_t)(source_val - source_min) *
>>>>>  		(target_max - target_min);
>>>>> -	do_div(target_val, source_max - source_min);
>>>>> +	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
>>>>>  	target_val += target_min;
>>>>>
>>>>>  	return target_val;
>>>>>
>>>> _______________________________________________
>>>> Intel-gfx mailing list
>>>> Intel-gfx@lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>> --
>>> Jani Nikula, Intel Open Source Technology Center
>>> _______________________________________________
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
index f17ada3..dcdfbb3 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -421,7 +421,7 @@  static uint32_t scale(uint32_t source_val,
 	/* avoid overflows */
 	target_val = (uint64_t)(source_val - source_min) *
 		(target_max - target_min);
-	do_div(target_val, source_max - source_min);
+	target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min);
 	target_val += target_min;
 
 	return target_val;