[alsa-devel] [PATCH 4/5] ASoC: fsl_ssi: use flat regmap cache

[Marek Vasut]

On 09/22/2016 12:18 AM, Maciej S. Szmigiero wrote:
> On 21.09.2016 21:32, Marek Vasut wrote:
>> On 09/21/2016 06:28 PM, Maciej S. Szmigiero wrote:
>>> Hi Marek,
>>
>> Hi!
>>
>>> On 19.09.2016 21:30, Marek Vasut wrote:
> (..)
>>>> The RB-tree regmap cache needs to allocate new space on first
>>>> writes.
>>>
>>> That's why SSI driver had .num_reg_defaults_raw set in regmap config.
>>> With this set and .reg_defaults_raw unset regcache_hw_init() will read
>>> existing register content which then will be used to populate cache
>>> (and so allocate RB tree nodes) at regcache initialization time.
>>
>> OK
>>
>>> This means that allocation of new cache RB tree nodes should never happen
>>> during actual write.
>>> If you get a warning that it happened then maybe there is a write to
>>> some register not covered by .num_reg_defaults_raw - this should be
>>> fixed.
>>
>> I might be blind, but I really don't see that. I just discussed it with
>> Mark and he thinks the same. I will revisit this one more time.
> 
> Maybe it would be possible to get a backtrace when that warning was
> generated so we know which register write or update triggers new cache
> allocation?

See patch 5/5 .

>>> The problem with flat cache is that it is zero-initialized, that is,
>>> all registers are assumed to contain zeros by default.
>>> This is generally not true in case of SSI so reads from and bit updates
>>> in non-volatile registers will corrupt their value.
>>
>> This will let the driver init the hardware into a well-defined state.
>> Are there any bits in the SSI config registers which we must preserve?
> 
> Hard to tell, this would need to be checked, but when datasheet values
> were used as cache defaults the SoC locked up when the fsl_ssi module
> was reloaded, at least in AC'97 mode.
> 
> I guess with zeros as defaults similar problems could occur.

I don't observe any problem either way on MX6SX , which should cover
also most of the MX6es.

> Maciej
> 


-- 
Best regards,
Marek Vasut