[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141104202638.GZ3815@sirena.org.uk>
Date: Tue, 4 Nov 2014 20:26:38 +0000
From: Mark Brown <broonie@...nel.org>
To: Mike Looijmans <mike.looijmans@...ic.nl>
Cc: lgirdwood@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] Add ltc3562 voltage regulator driver
On Tue, Nov 04, 2014 at 07:50:45AM +0100, Mike Looijmans wrote:
> v3: Add .of_match_table and prefix lltc
> Clarify why regmap cannot be used
> Add lltc,operating-mode (0..3) DT property
> regulator child nodes are optional
Leave out the mode setting in the DT for now please, Javier was looking
at adding a standard property for this with a driver defined mapping to
modes - you should implement the standard get_mode() and set_mode() (but
can always do that as a followup).
> +/* the LTC3562 does not have a register map, instead it receives a two-byte
> + * command set. The first byte sets the mask for the output(s) to be programmed
> + * and the second byte hold the "enable" bit and the DAC code. */
> +struct ltc3562_status {
> + u8 addr_mode; /* sub-address byte: program mask an operating mode */
> + u8 enable_daccode; /* data byte: Enable bit and DAC code */
> +};
So, I managed to find a datasheet[1] and this does actually seem to be a
standard register map. It looks like this is a 4x12 register map with
the program bytes being essentially register addresses (called sub
addresses in the datasheet), two pad bits (normally we'd include these
in the data for convenience) and the rest of the bits data. What am I
missing here?
Otherwise this looks good.
[1] http://cds.linear.com/docs/en/datasheet/3562fa.pdf
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists