All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.