Hi Thierry,
On Thu, 10 Mar 2016 18:54:38 +0100
Thierry Reding wrote:
> On Mon, Mar 07, 2016 at 08:34:19AM -0800, Doug Anderson wrote:
> > Thierry,
> >
> > On Thu, Feb 25, 2016 at 3:14 PM, Doug Anderson wrote:
> > > So just to summarize:
> > >
> >
On Mon, Mar 07, 2016 at 08:34:19AM -0800, Doug Anderson wrote:
> Thierry,
>
> On Thu, Feb 25, 2016 at 3:14 PM, Doug Anderson wrote:
> > So just to summarize:
> >
> > * Add pwm_get_state(), pwm_apply_state(), pwm_get_args().
> > pwm_get_state() initially returns 0 for duty
Thierry,
On Thu, Feb 25, 2016 at 3:14 PM, Doug Anderson wrote:
> So just to summarize:
>
> * Add pwm_get_state(), pwm_apply_state(), pwm_get_args().
> pwm_get_state() initially returns 0 for duty cycle if driver doesn't
> support readout.
>
> * Re-implement pwm_get_period()
Thierry,
On Tue, Feb 23, 2016 at 10:42 AM, Doug Anderson wrote:
> Thierry,
>
> On Tue, Feb 23, 2016 at 10:14 AM, Thierry Reding
> wrote:
>>> pwm_get_period(): get the period of the PWM; if the PWM has not yet
>>> been configured by software this
Thierry,
On Tue, Feb 23, 2016 at 10:14 AM, Thierry Reding
wrote:
>> pwm_get_period(): get the period of the PWM; if the PWM has not yet
>> been configured by software this gets the default period (possibly
>> specified by the device tree).
>
> No. I think we'll need a
On Tue, Feb 23, 2016 at 09:35:48AM -0800, Doug Anderson wrote:
> On Tue, Feb 23, 2016 at 6:38 AM, Thierry Reding
> wrote:
[...]
> > That's not quite what I was thinking. If hardware readout is supported
> > then whatever we report back should be the current hardware
Thierry,
On Tue, Feb 23, 2016 at 6:38 AM, Thierry Reding
wrote:
>> > Furthermore it's out of the question that changes to the API will be
>> > required. That's precisely the reason why the atomic PWM proposal came
>> > about. It's an attempt to solve the shortcomings of
On Thu, Feb 04, 2016 at 03:01:50PM +0100, Boris Brezillon wrote:
> Hi Mark, Thierry,
>
> On Thu, 4 Feb 2016 11:02:03 +
> Mark Brown wrote:
>
> > On Wed, Feb 03, 2016 at 11:04:20AM -0800, Doug Anderson wrote:
> >
> > > Sure. ...but you agree that somehow you need a new
On Mon, Feb 22, 2016 at 11:15:09AM -0800, Doug Anderson wrote:
> Thierry,
>
> On Mon, Feb 22, 2016 at 9:59 AM, Thierry Reding
> wrote:
[...]
> >> When we add a new feature then it's expected that only updated drivers
> >> will support that feature.
> >>
> >> We need to
Mark,
On Mon, Feb 22, 2016 at 1:24 PM, Mark Brown wrote:
> On Mon, Feb 22, 2016 at 11:15:09AM -0800, Doug Anderson wrote:
>
>> Note that historically I remember that Linus Torvalds has stated that
>> there is no stable API within the Linux kernel and that forcing the
>>
On Mon, Feb 22, 2016 at 11:15:09AM -0800, Doug Anderson wrote:
> Note that historically I remember that Linus Torvalds has stated that
> there is no stable API within the Linux kernel and that forcing the
> in-kernel API to never change was bad for software development. I
> tracked down my
Thierry,
On Mon, Feb 22, 2016 at 9:59 AM, Thierry Reding
wrote:
>> This is because only some drivers would be able to read the hardware
>> state? I'm not sure how we can get away from that. In all proposals
>> we've talked about (including what you propose below,
On Wed, Feb 03, 2016 at 11:04:20AM -0800, Doug Anderson wrote:
> Thierry
>
> On Wed, Feb 3, 2016 at 6:53 AM, Thierry Reding
> wrote:
> >> A) The software state here is the period and flags (AKA "inverted),
> >> right? It does seem possible that you could apply the
Thierry,
On Wed, Feb 3, 2016 at 11:04 AM, Doug Anderson wrote:
> Thierry
>
> On Wed, Feb 3, 2016 at 6:53 AM, Thierry Reding
> wrote:
>>> A) The software state here is the period and flags (AKA "inverted),
>>> right? It does seem possible that you
On Wed, Feb 03, 2016 at 11:04:20AM -0800, Doug Anderson wrote:
> Sure. ...but you agree that somehow you need a new API call for this,
> right? Somehow the PWM regulator needs to be able to say that it
> wants the hardware state, not the initial state as specified in the
> device tree.
On Mon, Jan 25, 2016 at 10:51:20AM -0800, Doug Anderson wrote:
> Hi,
>
> On Mon, Jan 25, 2016 at 9:08 AM, Thierry Reding
> wrote:
> > I really don't understand this design decision. I presume that the PWM
> > controlling this system-critical logic is driven by the SoC?
Thierry
On Wed, Feb 3, 2016 at 6:53 AM, Thierry Reding wrote:
>> A) The software state here is the period and flags (AKA "inverted),
>> right? It does seem possible that you could apply the period and
>> flags while keeping the calculated bootup duty cycle percentage
On Mon, Jan 25, 2016 at 08:28:31AM -0800, Doug Anderson wrote:
> Thierry and Boris,
>
> On Tue, Nov 10, 2015 at 9:34 AM, Thierry Reding
> wrote:
> > On Mon, Oct 19, 2015 at 12:12:12PM +0200, Heiko Stübner wrote:
> >> Hi Thierry,
> >>
> >> Am Montag, 21. September 2015,
Thierry and Boris,
On Tue, Nov 10, 2015 at 9:34 AM, Thierry Reding
wrote:
> On Mon, Oct 19, 2015 at 12:12:12PM +0200, Heiko Stübner wrote:
>> Hi Thierry,
>>
>> Am Montag, 21. September 2015, 11:33:17 schrieb Boris Brezillon:
>> > Hello,
>> >
>> > This series adds
Hi Thierry,
On Mon, 25 Jan 2016 18:08:55 +0100
Thierry Reding wrote:
> On Mon, Jan 25, 2016 at 08:28:31AM -0800, Doug Anderson wrote:
> > Thierry and Boris,
> >
> > On Tue, Nov 10, 2015 at 9:34 AM, Thierry Reding
> > wrote:
> > > On Mon, Oct
Hi,
On Mon, Jan 25, 2016 at 9:08 AM, Thierry Reding
wrote:
> I really don't understand this design decision. I presume that the PWM
> controlling this system-critical logic is driven by the SoC? So if the
> regulator is system-critical, doesn't that make it a chicken
Hi Thierry,
On Tue, 10 Nov 2015 18:34:16 +0100
Thierry Reding wrote:
> On Mon, Oct 19, 2015 at 12:12:12PM +0200, Heiko Stübner wrote:
> > Hi Thierry,
> >
> > Am Montag, 21. September 2015, 11:33:17 schrieb Boris Brezillon:
> > > Hello,
> > >
> > > This series adds
On Mon, Oct 19, 2015 at 12:12:12PM +0200, Heiko Stübner wrote:
> Hi Thierry,
>
> Am Montag, 21. September 2015, 11:33:17 schrieb Boris Brezillon:
> > Hello,
> >
> > This series adds support for atomic PWM update, or IOW, the capability
> > to update all the parameters of a PWM device
Hi Thierry,
Am Montag, 21. September 2015, 11:33:17 schrieb Boris Brezillon:
> Hello,
>
> This series adds support for atomic PWM update, or IOW, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one go.
is anything more blocking
Hi Thierry,
On Mon, 21 Sep 2015 11:33:17 +0200
Boris Brezillon wrote:
> Hello,
>
> This series adds support for atomic PWM update, or IOW, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one
Hi Boris,
Am Montag, 21. September 2015, 11:33:17 schrieb Boris Brezillon:
> This series adds support for atomic PWM update, or IOW, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one go.
I gave this v3 a spin on a rk3288-veyron
26 matches
Mail list logo