[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180616184907.5831c24a@archlinux>
Date: Sat, 16 Jun 2018 18:49:07 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Stefan Popa <stefan.popa@...log.com>,
Michael Hennerich <Michael.Hennerich@...log.com>,
Lars-Peter Clausen <lars@...afoo.de>,
Hartmut Knaack <knaack.h@....de>,
Peter Meerwald <pmeerw@...erw.net>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Greg KH <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Randy Dunlap <rdunlap@...radead.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, linux-iio@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] dt-bindings: iio: dac: Add docs for AD5758 DAC
On Mon, 11 Jun 2018 10:42:35 +0200
Linus Walleij <linus.walleij@...aro.org> wrote:
> On Thu, Jun 7, 2018 at 3:11 PM, Stefan Popa <stefan.popa@...log.com> wrote:
>
> > + - adi,slew: Array of slewrate settings should contain 3 fields:
> > + 1: Should be either 0 or 1 in order to enable or disable slewrate.
>
> We have a standard binding in pin control for "slew-rate".
>
> It doesn't have a unit today though.
>
> > + 2: Slew rate clock:
> > + Valid values for the slew rate update frequency [Hz]:
> > + * 240000
> > + * 200000
> > + * 150000
> > + * 128000
> > + * 64000
> > + * 32000
> > + * 16000
> > + * 8000
> > + * 4000
> > + * 2000
> > + * 1000
> > + * 512
> > + * 256
> > + * 128
> > + * 64
> > + * 16
> > + 3: Slew rate step:
> > + Defines by how much the output value changes at each update.
> > + Valid values for the step size LSBs:
> > + * 4
> > + * 12
> > + * 64
> > + * 120
> > + * 256
> > + * 500
> > + * 1820
> > + * 2048
>
> This is pretty idiomatic and just encodes the configuration fields from the
> hardware into the device tree.
>
> The normal slew rate unit is Volts per microsecond.
>
> I get the feeling that we could define that simply, and then calculate
> the slew rate clock and step using that to find the best match for
> a certain slew rate.
>
> Yours,
> Linus Walleij
Agreed. A single value would be nice if possible.
J
Powered by blists - more mailing lists