All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jingoo Han <jingoohan1@gmail.com>,
	linux-fbdev@vger.kernel.org, Lee Jones <lee.jones@linaro.org>,
	dri-devel@lists.freedesktop.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH 5/5] backlight: led_bl: rewrite led_bl_parse_levels()
Date: Tue, 21 Apr 2020 11:53:02 +0000	[thread overview]
Message-ID: <476ec68b-da2b-2f29-bc0a-3d61b4fc3eb6@ti.com> (raw)
In-Reply-To: <0c7d02aa-db51-1c6f-e126-88472db4345b@ti.com>

On 21/04/2020 14:26, Tomi Valkeinen wrote:

>>> The led-backlight.txt is
>>> a bit lacking (another thing to improve...) but led-backlight mimics
>>> pwm-backlight, and pwm-backlight.txt says
>>>
>>> default-brightness-level: The default brightness level (index into the array
>>> defined by the "brightness-levels" property)
>>
>> I think this implies we should improve the binding documentation!
>>
>> The parenthetic text's main purpose is to make clear which scale should
>> be used when interpreting the default brightness. Just because the scale
>> is 1:1 doesn't render it meaningless.
> 
> If I read pwm_bl.c right, that's not how the code works. If pwm_bl has no 'brightness-levels', then 
> 'default-brightness-level' is ignored. Which matches the binding documentation.
> 
> What you suggest makes sense, though, so I can adjust this patch to make led_bl behave like that.

On the other hand... If we want to use LED's (or PWM's) brightness levels directly, should the 
default brightness be defined in the LED's (or PWM's) DT node?

And only if we create a backlight brightness-levels mapping, we need to add a new property to define 
a default for those levels. Which, I think, the name implies with the "-level".

Well, in any case, there should be no harm in using 'default-brightness-level' also for the 1:1 
mapping without the 'brightness-levels'. So maybe that's the best route.

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jingoo Han <jingoohan1@gmail.com>,
	linux-fbdev@vger.kernel.org, Lee Jones <lee.jones@linaro.org>,
	dri-devel@lists.freedesktop.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH 5/5] backlight: led_bl: rewrite led_bl_parse_levels()
Date: Tue, 21 Apr 2020 14:53:02 +0300	[thread overview]
Message-ID: <476ec68b-da2b-2f29-bc0a-3d61b4fc3eb6@ti.com> (raw)
In-Reply-To: <0c7d02aa-db51-1c6f-e126-88472db4345b@ti.com>

On 21/04/2020 14:26, Tomi Valkeinen wrote:

>>> The led-backlight.txt is
>>> a bit lacking (another thing to improve...) but led-backlight mimics
>>> pwm-backlight, and pwm-backlight.txt says
>>>
>>> default-brightness-level: The default brightness level (index into the array
>>> defined by the "brightness-levels" property)
>>
>> I think this implies we should improve the binding documentation!
>>
>> The parenthetic text's main purpose is to make clear which scale should
>> be used when interpreting the default brightness. Just because the scale
>> is 1:1 doesn't render it meaningless.
> 
> If I read pwm_bl.c right, that's not how the code works. If pwm_bl has no 'brightness-levels', then 
> 'default-brightness-level' is ignored. Which matches the binding documentation.
> 
> What you suggest makes sense, though, so I can adjust this patch to make led_bl behave like that.

On the other hand... If we want to use LED's (or PWM's) brightness levels directly, should the 
default brightness be defined in the LED's (or PWM's) DT node?

And only if we create a backlight brightness-levels mapping, we need to add a new property to define 
a default for those levels. Which, I think, the name implies with the "-level".

Well, in any case, there should be no harm in using 'default-brightness-level' also for the 1:1 
mapping without the 'brightness-levels'. So maybe that's the best route.

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-04-21 11:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 11:33 [PATCH 1/5] backlight: led_bl: fix cosmetic issues Tomi Valkeinen
2020-04-17 11:33 ` Tomi Valkeinen
2020-04-17 11:33 ` [PATCH 2/5] backlight: led_bl: drop useless NULL initialization Tomi Valkeinen
2020-04-17 11:33   ` Tomi Valkeinen
2020-04-20 15:29   ` Daniel Thompson
2020-04-20 15:29     ` Daniel Thompson
2020-04-17 11:33 ` [PATCH 3/5] backlight: led_bl: add led_access locking Tomi Valkeinen
2020-04-17 11:33   ` Tomi Valkeinen
2020-04-20 15:45   ` Daniel Thompson
2020-04-20 15:45     ` Daniel Thompson
2020-04-17 11:33 ` [PATCH 4/5] backlight: led_bl: fix led -> backlight brightness mapping Tomi Valkeinen
2020-04-17 11:33   ` Tomi Valkeinen
2020-04-20 15:55   ` Daniel Thompson
2020-04-20 15:55     ` Daniel Thompson
2020-04-21  5:57     ` Tomi Valkeinen
2020-04-21  5:57       ` Tomi Valkeinen
2020-04-17 11:33 ` [PATCH 5/5] backlight: led_bl: rewrite led_bl_parse_levels() Tomi Valkeinen
2020-04-17 11:33   ` Tomi Valkeinen
2020-04-20 16:01   ` Daniel Thompson
2020-04-20 16:01     ` Daniel Thompson
2020-04-21  5:52     ` Tomi Valkeinen
2020-04-21  5:52       ` Tomi Valkeinen
2020-04-21 10:48       ` Daniel Thompson
2020-04-21 10:48         ` Daniel Thompson
2020-04-21 11:26         ` Tomi Valkeinen
2020-04-21 11:26           ` Tomi Valkeinen
2020-04-21 11:53           ` Tomi Valkeinen [this message]
2020-04-21 11:53             ` Tomi Valkeinen
2020-04-20 15:29 ` [PATCH 1/5] backlight: led_bl: fix cosmetic issues Daniel Thompson
2020-04-20 15:29   ` Daniel Thompson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=476ec68b-da2b-2f29-bc0a-3d61b4fc3eb6@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=daniel.thompson@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jingoohan1@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-fbdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.