From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751349AbdIELFx (ORCPT <rfc822;w@1wt.eu>);
        Tue, 5 Sep 2017 07:05:53 -0400
Received: from mail-wm0-f46.google.com ([74.125.82.46]:37888 "EHLO
        mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750794AbdIELFu (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 5 Sep 2017 07:05:50 -0400
X-Google-Smtp-Source: ADKCNb6uHlclsOcjVp+laOlhEDfblpSwtOM0teBJpmDxoT24h7U8USjXMjECrzp/c3xvrzhPp0vb6A==
Subject: Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human
 eye
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>,
        Lee Jones <lee.jones@linaro.org>, Jingoo Han <jingoohan1@gmail.com>,
        Richard Purdie <rpurdie@rpsys.net>,
        Jacek Anaszewski <jacek.anaszewski@gmail.com>,
        Pavel Machek <pavel@ucw.cz>, Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Doug Anderson <dianders@google.com>,
        Brian Norris <briannorris@google.com>,
        Guenter Roeck <groeck@google.com>
Cc: linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20170904153504.27963-1-enric.balletbo@collabora.com>
From: Daniel Thompson <daniel.thompson@linaro.org>
Message-ID: <239c9153-c0ea-319c-b554-3c727b75c8cd@linaro.org>
Date: Tue, 5 Sep 2017 12:05:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170904153504.27963-1-enric.balletbo@collabora.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 04/09/17 16:35, Enric Balletbo i Serra wrote:
> Dear all,
> 
> This patch series is a first RFC to know your opinion about implement
> support to create brightness levels tables dinamically. I tried to argue
> in every patch the specific reasons we think this can be interesting, to
> sumup, the idea behind these patches is be able to pass via device tree
> two parameters to the driver so it can calculate the brightness levels
> based on the CIE 1931 lightness formula, which is what actually describes
> how we perceive light.
> 
> I think that at least the maths involved can be improved, and I've still
> some doubts. With current code if you create a table with a max PWM
> value of 255 and 127 steps, the first numbers are repeated so I'm thinking > that maybe we should skip/remove the repeated values. i.e. have a table
> like this,
> 
> [0, 1, 2, 3  ...  235, 240, 245, 250, 255]
> 
> instead of
> 
> [0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3  ...  235, 240, 245, 250, 255]
> 
> Well, I know there are things to improve but lets see your feedback first
> before dedicate more time on it. The patches were tested on a couple of
> devices but I'll test on more devices meanwhile we discuss about it.

I'm not fully decided on this one but my initial reaction isn't to 
question the concept so much as to ask why the number of levels should 
go in the devicetree at all! We could just make brightness-levels 
optional and get the driver to pick sane curves by default.

I'm sure we can debate what "sane" means for a couple of e-mails yet but 
in principle, given it knows the PWM max counter value, the driver 
should be able to calculate the "right" number of steps too. If we have 
that your core code remains but we don't have to complexify the device

<strawman>
Basically we prefer X (?100 like some of the Intel DRM drivers do for 
connector properties?) steps but we reduce the number of steps if the 
PWM is rather course and we can't get sufficiently different steps.
</strawman>

I guess the summary of what I'm saying is that if we can 
programmatically derive brightness curves then the number of steps is 
not really a property of the hardware and doesn't belong in devicetree.


Daniel.