On 10/08/2022 14:37, Mark Brown wrote:
On Wed, Aug 10, 2022 at 11:17:14AM +0200, Neil Armstrong wrote:
On 09/08/2022 17:27, Mark Brown wrote:
On Tue, Aug 09, 2022 at 05:20:19PM +0200, Neil Armstrong wrote:
When you say the value set by the clock framework does that mean that
the clock driver is adjusting hardware inside the SPI controller IP
block which is then getting reset by the SPI driver without the SPI
driver knowing about it? That seems like a bad idea as you're finding
here.
The SPI driver is explicitely triggering a reset at the end of each message
to get back to a clean HW state, but it does reset the content of the "legacy"
registers containing the power of 2 divider value, the new registers configuring
the new clock divider path (only on newer SoCs) doesn't get cleared.
Sure, but that doesn't really address the concern - is this something
that the clk driver programmed or is this the driver forgetting to
restore a register that it programmed itself? The commit message sounds
like the former which is a much bigger problem.
It's what is programmed by the Clock Framework yes, it was designed as-is
so the Clock Framework takes the most accurate clock path but the reset case
wasn't taken in account.
Neil
