linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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/


  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).