regmap: Question about devices with unequal register sizes

regmap: Question about devices with unequal register sizes

[Daniel Mack]

Hi Mark and everyone,

I'm writing a driver for an I2C audio codec which has an unusual
register map. The datasheet can be found here:

  http://www.ti.com/lit/gpn/tas5086

The register layout is described on page 26, and they call their
registers 'subaddresses'. Up to sub-address 0x1c, I see no problem
mapping that to a simple 8-bit regmap layout, but above that, access
gets trickier because registers change their sizes, which breaks the cache.

So for example, in order to set the 'Downmix input MUX register', the
host is expected to send the sub-address 0x21, followed by 4 consecutive
bytes containing the values. 0x21 is, however, not the correct offset in
the register cache, as 0x20 ('Input MUX register') is also 4 bytes in
size. Higher registers also have to be written in 20 byte blocks.

I thought about registering multiple regmaps with the i2c device, but
that turns out not to play well with ASoC, which always takes the first
regmap for the device.

Are ranges within in the regmap_config what I want here? I haven't yet
figured how to use them accordingly though.

Thanks for sharing any ideas.


Best regards,
Daniel

Re: regmap: Question about devices with unequal register sizes

[Mark Brown]

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

On Sat, Feb 16, 2013 at 06:03:51PM +0100, Daniel Mack wrote:

> The register layout is described on page 26, and they call their
> registers 'subaddresses'. Up to sub-address 0x1c, I see no problem
> mapping that to a simple 8-bit regmap layout, but above that, access
> gets trickier because registers change their sizes, which breaks the cache.

The regmap I/O code isn't making any effort to support such devices, the
hardware is just too crazy to worry about.  The best you can do is use
the no-bus support and open code your physical I/O so you can still use
the cache.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: regmap: Question about devices with unequal register sizes

[Daniel Mack]

On 17.02.2013 17:23, Mark Brown wrote:
> On Sat, Feb 16, 2013 at 06:03:51PM +0100, Daniel Mack wrote:
> 
>> The register layout is described on page 26, and they call their
>> registers 'subaddresses'. Up to sub-address 0x1c, I see no problem
>> mapping that to a simple 8-bit regmap layout, but above that, access
>> gets trickier because registers change their sizes, which breaks the cache.
> 
> The regmap I/O code isn't making any effort to support such devices, the
> hardware is just too crazy to worry about.  The best you can do is use
> the no-bus support and open code your physical I/O so you can still use
> the cache.

So it turns out I need to write these registers now on the TAS5086
codec, which has such a strange layout. I wonder how I can possibly open
code the physical I/O with registers that are up to 20 bytes in size,
while the reg_write callback in struct regmap_config assumes an unsigned
int suffices for the data? Any example you can point me to?


Thanks,
Daniel

Re: regmap: Question about devices with unequal register sizes

[Mark Brown]

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

On Mon, May 06, 2013 at 06:32:12PM +0200, Daniel Mack wrote:
> On 17.02.2013 17:23, Mark Brown wrote:

> > The regmap I/O code isn't making any effort to support such devices, the
> > hardware is just too crazy to worry about.  The best you can do is use
> > the no-bus support and open code your physical I/O so you can still use
> > the cache.

> So it turns out I need to write these registers now on the TAS5086
> codec, which has such a strange layout. I wonder how I can possibly open
> code the physical I/O with registers that are up to 20 bytes in size,
> while the reg_write callback in struct regmap_config assumes an unsigned
> int suffices for the data? Any example you can point me to?

There's just no attempt being made in regmap to cater for such devices.
I'm not sure it's worth bothering, sorry, though if you come up with a
non-intrusive way of handling such hardware of course it'd be worth
considering.

Using the no-bus support, having that take a lock and then bypassing it
completely to do the 20 byte writes would probably work.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]