linux-kernel - Re: [PATCH v6 1/2] regulator: st-pwm: get voltage and duty table from dts

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: <CAD=FV=URhXjY2eW7JnkrwR7zjGzLB9DshySUMX3AJjjstee=KA@mail.gmail.com>
Date:	Tue, 23 Sep 2014 20:40:28 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Chris Zhong <zyw@...k-chips.com>
Cc:	Heiko Stübner <heiko@...ech.de>,
	linux-rockchip@...ts.infradead.org,
	Lee Jones <lee.jones@...aro.org>,
	"broonie@...nel.org" <broonie@...nel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v6 1/2] regulator: st-pwm: get voltage and duty table from dts

Chris,

On Tue, Sep 23, 2014 at 7:51 PM, Chris Zhong <zyw@...k-chips.com> wrote:
>
> On 09/24/2014 10:13 AM, Doug Anderson wrote:
>>
>> Chris,
>>
>> On Tue, Sep 23, 2014 at 6:47 PM, Chris Zhong <zyw@...k-chips.com> wrote:
>>>
>>> On 09/24/2014 07:43 AM, Doug Anderson wrote:
>>>>
>>>> Chris,
>>>>
>>>> On Tue, Sep 23, 2014 at 8:53 AM, Chris Zhong <zyw@...k-chips.com> wrote:
>>>>>
>>>>> Get voltage & duty table from device tree might be better, other
>>>>> platforms can also use this
>>>>> driver without any modify.
>>>>>
>>>>> Signed-off-by: Chris Zhong <zyw@...k-chips.com>
>>>>> Reviewed-by: Doug Anderson <dianders@...omium.org>
>>>>
>>>> I finally managed to get everything setup and I've now tested this
>>>> myself on an rk3288-based board.
>>>>
>>>> Tested-by: Doug Anderson <dianders@...omium.org>
>>>>
>>>> I'd imagine the next step is for Lee to comment on the patch and when
>>>> he's happy with it Mark Brown will land it?
>>>>
>>>>
>>>> One thing that's still a bit odd (though no different than the
>>>> behavior of the driver from before you touched it, so it shouldn't
>>>> block landing IMHO) is that at boot time this regulator will report
>>>> that it's at the highest voltage but the voltage won't actually change
>>>> until the first client sets the voltage.
>>>
>>> Yes, I knew this problem, since the default of duty cycle is 0, not a
>>> true
>>> value.
>>> If we can get duty from pwm, this regulator will report a correct
>>> voltage.
>>
>> I don't think it's possible in all cases to figure out what the
>> voltage was before this regulator was probed.
>>
>> * pin might have been input w/ pullup, pulldown, or no pull
>> * pin might have been driven high or driven low
>>
>> In that case trying to read the duty from the pwm wouldn't make sense.
>> ...but I guess you could add a property to the PWM driver to say that
>> it stays enabled at boot if the FW left it enabled (and keep the same
>> duty cycle / clocks?).  That would at least solve the problem where
>> the firmware configured the PWM and left it in a specific state even
>> if it doesn't solve the above problem...
>>
>>
>> -Doug
>>
> If we want pwm stay enabled at boot(FW left it), needn't to modify anything,
> only need to init pwm duty in FW.
> And now reading the duty from pwm would make sense.

Maybe I'll understand better if you send up some patches.  I would
have thought that when the PWM initializes it would start out disabled
and there wouldn't be an easy way to convince the PWM subsystem to
keep it enabled.  ...I also would have thought that the default
behavior of a PWM on Linux would be to disable it in the driver probe
if firmware happened to have left it on.

I could be wrong on both counts, though.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/