quoted
+
+ /* restore registers by regcache_sync */
+ fsl_esai_register_restore(esai_priv);
+
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
+ ESAI_xCR_xPR_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR,
+ ESAI_xCR_xPR_MASK, 0);
And just for curious, can (or shall) we stuff this personal reset to the reset()
function? I found this one is a part of the reset routine being mentioned in
the RM -- it was done after ESAI reset is done via ECR register.
There is a problem to do this, TPR/RPR need to be clear after configure the control
register. (TCCR, TCR). So it seems not only one place (reset function) need to be
changed.
Best regards
Wang shengjiu
On Fri, Jul 05, 2019 at 07:03:47AM +0000, S.j. Wang wrote:
quoted
quoted
+
+ /* restore registers by regcache_sync */
+ fsl_esai_register_restore(esai_priv);
+
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
+ ESAI_xCR_xPR_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_RCR,
+ ESAI_xCR_xPR_MASK, 0);
And just for curious, can (or shall) we stuff this personal reset to the reset()
function? I found this one is a part of the reset routine being mentioned in
the RM -- it was done after ESAI reset is done via ECR register.
There is a problem to do this, TPR/RPR need to be clear after configure the control
register. (TCCR, TCR). So it seems not only one place (reset function) need to be
changed.
Do you know (or remember) why we suddenly involve this TPR/PRP?
The driver has no problem so far, even if we don't have them.
The "personal reset" sounds like a feature that we would use to
reset TX or RX individually, while this hw_reset() does a full
reset for both TX and RX. So I wonder whether they're necessary.