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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
