[PATCH] regmap: Add support for 12/20 register formatting

[PATCH] regmap: Add support for 12/20 register formatting

[Ricardo Ribalda]

From: Ricardo Ribalda <ricardo@ribalda.com>

Devices such as the AD5628 require 32 bits of data divided in 12 bits
for dummy, command and address, and 20 for data and dummy.

Signed-off-by: Ricardo Ribalda <ricardo@ribalda.com>
---
 drivers/base/regmap/regmap.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index e93700af7e6e..14cdfee4c6ba 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -209,6 +209,18 @@ static bool regmap_volatile_range(struct regmap *map, unsigned int reg,
 	return true;
 }
 
+static void regmap_format_12_20_write(struct regmap *map,
+				     unsigned int reg, unsigned int val)
+{
+	u8 *out = map->work_buf;
+
+	out[0] = reg >> 4;
+	out[1] = (reg << 4) | (val >> 16);
+	out[2] = val >> 8;
+	out[3] = val;
+}
+
+
 static void regmap_format_2_6_write(struct regmap *map,
 				     unsigned int reg, unsigned int val)
 {
@@ -867,6 +879,16 @@ struct regmap *__regmap_init(struct device *dev,
 		}
 		break;
 
+	case 12:
+		switch (config->val_bits) {
+		case 20:
+			map->format.format_write = regmap_format_12_20_write;
+			break;
+		default:
+			goto err_hwlock;
+		}
+		break;
+
 	case 8:
 		map->format.format_reg = regmap_format_8;
 		break;
-- 
2.28.0

Re: [PATCH] regmap: Add support for 12/20 register formatting

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Wed, Sep 16, 2020 at 06:05:52PM +0200, Ricardo Ribalda wrote:
> From: Ricardo Ribalda <ricardo@ribalda.com>
> 
> Devices such as the AD5628 require 32 bits of data divided in 12 bits
> for dummy, command and address, and 20 for data and dummy.

What exactly is the format you're trying to describe here?  It sounds
like there's two blocks of padding in here (I'm assuing that's what
dummy means) but what's the exact arrangement here and what are the
commands?  It sounds like this might not work ideally with things like
the cache code (if it makes things seems sparser than they are) and
might not be obvious to someone looking at the datsheet.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] regmap: Add support for 12/20 register formatting

[Ricardo Ribalda Delgado]

Hi Mark




On Wed, Sep 16, 2020 at 6:29 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Sep 16, 2020 at 06:05:52PM +0200, Ricardo Ribalda wrote:
> > From: Ricardo Ribalda <ricardo@ribalda.com>
> >
> > Devices such as the AD5628 require 32 bits of data divided in 12 bits
> > for dummy, command and address, and 20 for data and dummy.
>
> What exactly is the format you're trying to describe here?  It sounds
> like there's two blocks of padding in here (I'm assuing that's what
> dummy means) but what's the exact arrangement here and what are the
> commands?  It sounds like this might not work ideally with things like
> the cache code (if it makes things seems sparser than they are) and
> might not be obvious to someone looking at the datsheet.

The format is

XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX

Where X is dont care, C is command, A is address and D is data bits. I
am using the following config successfully:

static const struct regmap_config config_dac = {
.reg_bits = 12,
.val_bits = 20,
.max_register = 0xff,
};

Shall I add this to the commit message? I want to send a V2 anyway,
because I screwed up the identity (ribalda.com instead of kernel.org)

Thanks

Re: [PATCH] regmap: Add support for 12/20 register formatting

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

On Thu, Sep 17, 2020 at 08:31:54AM +0200, Ricardo Ribalda Delgado wrote:
> On Wed, Sep 16, 2020 at 6:29 PM Mark Brown <broonie@kernel.org> wrote:

> > What exactly is the format you're trying to describe here?  It sounds
> > like there's two blocks of padding in here (I'm assuing that's what
> > dummy means) but what's the exact arrangement here and what are the
> > commands?  It sounds like this might not work ideally with things like
> > the cache code (if it makes things seems sparser than they are) and
> > might not be obvious to someone looking at the datsheet.

> The format is

> XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX

> Where X is dont care, C is command, A is address and D is data bits. I

> Shall I add this to the commit message? I want to send a V2 anyway,
> because I screwed up the identity (ribalda.com instead of kernel.org)

Yes, please.  I was fairly sure it worked, it was just a question of if
it was ideal for the format described.  The only issue I can see with
the above is that the users will need to left shift their data - on the
face of it it would seem better to add a facility for padding the LSBs
of the data field to the core so that users can just use the data field
as documented.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] regmap: Add support for 12/20 register formatting

[Ricardo Ribalda Delgado]

HI Mark

On Thu, Sep 17, 2020 at 1:22 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Sep 17, 2020 at 08:31:54AM +0200, Ricardo Ribalda Delgado wrote:
> > On Wed, Sep 16, 2020 at 6:29 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > What exactly is the format you're trying to describe here?  It sounds
> > > like there's two blocks of padding in here (I'm assuing that's what
> > > dummy means) but what's the exact arrangement here and what are the
> > > commands?  It sounds like this might not work ideally with things like
> > > the cache code (if it makes things seems sparser than they are) and
> > > might not be obvious to someone looking at the datsheet.
>
> > The format is
>
> > XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX
>
> > Where X is dont care, C is command, A is address and D is data bits. I
>
> > Shall I add this to the commit message? I want to send a V2 anyway,
> > because I screwed up the identity (ribalda.com instead of kernel.org)
>
> Yes, please.  I was fairly sure it worked, it was just a question of if
> it was ideal for the format described.  The only issue I can see with
> the above is that the users will need to left shift their data - on the
> face of it it would seem better to add a facility for padding the LSBs
> of the data field to the core so that users can just use the data field
> as documented.

I was thinking also about that, the problem is that there are many
devices on that family that are "software" compatible and it only
changes the width of the data. Eg:

DDDDDDDDDDDDDDDDXXXX
DDDDDDDDDDDDXXXXXXXX
DDDDDDDDXXXXXXXXXXXX

So if we need to make a driver, we could use the same driver for all
the chips on that family, saying to the user that the data size is
always 20 bits....

I will send v2 ASAP with the updated doc.

Thanks