Messages in this thread | | | Date | Wed, 5 Nov 2014 13:34:08 +0000 | From | Mark Brown <> | Subject | Re: [PATCH v3] Add ltc3562 voltage regulator driver |
| |
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. [unhandled content-type:application/pgp-signature] | |