linux-kernel - Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 Jul 2017 17:46:04 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Chen-Yu Tsai <wens@...e.org>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Shiraz Hashim <shashim@...eaurora.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

On Thu, Jul 13, 2017 at 1:09 PM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 13-07-17, 10:52, Chen-Yu Tsai wrote:
>> I'm afraid the regulator case still doesn't make sense. The voltage
>> constraints should be set within each supplies device node. This was
>> explained in the discussion in v1 [1].
>
> I thought we were discussing about something I mentioned in one of my example
> but never to a point that the regulator problem doesn't exist at all. Perhaps I
> misunderstood your concerns. Anyway, lemme try once more with a better example.
>
> Regulator shared by: LCD and MMC (both can do DVFS) and the min/max constraint
> that can be set by the consumers of the regulator (both LCD/MMC) are: 1.5 V to
> 3 V.
>
> The bootloader has programmed the LCD to work at the highest pixel frequency,
> which needs the voltage to be in range from 2.5 - 3 V.
>
> Now MMC can get probed first and it can try to bring the voltages below 2.5 V.
> Though, 1.5 - 2.5 is a valid range for the LCD, but not at the current pixel
> frequency.
>
> Does that sound like a valid problem?

This makes more sense. The LCD being able to do DVFS was missing from the last
discussion. I assume this is for power saving purposes? Otherwise one could just
say you should not use the lower part of the voltage range. And DVFS is for the
controller's core logic and not I/O?

ChenYu