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