Re: [PATCH v3] Add ltc3562 voltage regulator driver

From: Mark Brown
Date: Wed Nov 05 2014 - 08:34:49 EST


On Wed, Nov 05, 2014 at 12:41:34PM +0100, Mike Looijmans wrote:
> ïOn 11/04/2014 09:26 PM, Mark Brown wrote:

> >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?

> Things that makes me think it's NOT a register map:
> - You cannot read from the device

That's entirely normal for older devices, on larger process nodes the
extra digital to implement read was expensive enough for people to care
and I believe there were some IP issues with implementing read support.

> - You always have to send a complete command set (two bytes)
> - There is data (the regulator mode) in the address byte

Having to send both a register and a value is the standard thing, and
with older write only devices things frequently weren't full byte
multiples, 7x9 was extremely common.

> - The 'address' is not an index but a bitmask in bits 4..7

That's just a sparse register map, again very common (you'll also often
see holes in the register map due to undocumented registers or with
larger register addresses just to keep the map neat).

> I fail to see the use for regmap here, but if your view on this is "regmap
> or burst" then I'll implement it.

The biggest advantage is that it means that a large proportion of the
code in the driver can be removed and standard implementations in the
core used instead. In general removing code is good and this means that
if we do things like impement support for enabling and disabling
multiple regulators with a single write then the driver will support
this for free.

Attachment: signature.asc
Description: Digital signature