From: Mike Looijmans <mike.looijmans@topic.nl>
To: Mark Brown <broonie@kernel.org>
Cc: <lgirdwood@gmail.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] Add ltc3562 voltage regulator driver
Date: Wed, 5 Nov 2014 12:41:34 +0100 [thread overview]
Message-ID: <545A0CEE.2050101@topic.nl> (raw)
In-Reply-To: <20141104202638.GZ3815@sirena.org.uk>
On 11/04/2014 09:26 PM, Mark Brown wrote:
> 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
>
Things that makes me think it's NOT a register map:
- You cannot read from the device
- You always have to send a complete command set (two bytes)
- There is data (the regulator mode) in the address byte
- The 'address' is not an index but a bitmask in bits 4..7
Yeah, I think you can force-feed this to regmap. It will just make the code
considerably bigger and harder to understand, and as far as I know, the one
and only advantage this will bring is that you can dump the current
"registers" (4x10 bits of data) via /sys/kernel/debug/regmap.
I fail to see the use for regmap here, but if your view on this is "regmap or
burst" then I'll implement it.
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl
Please consider the environment before printing this e-mail
Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/
next prev parent reply other threads:[~2014-11-05 11:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 8:15 Add ltc3562 voltage regulator driver Mike Looijmans
2014-10-29 8:16 ` [PATCH] " Mike Looijmans
2014-10-29 12:30 ` Mark Brown
2014-10-30 6:47 ` Mike Looijmans
2014-10-30 10:15 ` Mark Brown
2014-10-30 10:29 ` Mike Looijmans
2014-10-30 10:53 ` Mike Looijmans
2014-10-30 10:58 ` Mark Brown
2014-10-30 11:31 ` Mike Looijmans
2014-10-30 12:04 ` Mark Brown
2014-10-30 11:26 ` [PATCH v2] " Mike Looijmans
2014-10-30 16:51 ` Mark Brown
2014-10-31 14:07 ` Mike Looijmans
2014-10-31 18:17 ` Mark Brown
2014-11-03 8:10 ` Mike Looijmans
2014-11-03 12:09 ` Mark Brown
2014-11-03 14:48 ` Mike Looijmans
2014-11-03 15:10 ` Mark Brown
2014-11-03 17:38 ` Mike Looijmans
2014-11-04 8:55 ` Mike Looijmans
2014-11-04 11:34 ` Mark Brown
2014-11-04 12:47 ` Mike Looijmans
2014-11-04 13:35 ` Mike Looijmans
2014-11-04 19:47 ` Mark Brown
2014-11-05 9:06 ` Krzysztof Kozlowski
2014-11-05 11:45 ` Mike Looijmans
2014-11-04 6:50 ` [PATCH v3] " Mike Looijmans
2014-11-04 20:26 ` Mark Brown
2014-11-05 11:41 ` Mike Looijmans [this message]
2014-11-05 13:34 ` Mark Brown
2014-10-29 10:03 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=545A0CEE.2050101@topic.nl \
--to=mike.looijmans@topic.nl \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).