linux.git/drivers/soundwire/intel.c, branch v6.4.1

soundwire: intel: don't save hw_params for use in prepare

2023-04-12T10:02:57+00:00

The existing code copies the hw_params pointer and reuses it later in
.prepare, specifically to re-initialize the ALH DMA channel
information that's lost in suspend-resume cycles.

This is not needed, we can directly access the information from the
substream/rtd - as done for the HDAudio DAIs in
sound/soc/sof/intel/hda-dai.c

In addition, using the saved pointer causes the suspend-resume test
cases to fail on specific platforms, depending on which version of GCC
is used. Péter Ujfalusi and I have spent long hours to root-cause this
problem that was reported by the Intel CI first with 6.2-rc1 and again
v6.3-rc1. In the latter case we were lucky that the problem was 100%
reproducible on local test devices, and found out that adding a
dev_dbg() or adding a call to usleep_range() just before accessing the
saved pointer "fixed" the issue. With errors appearing just by
changing the compiler version or minor changes in the code generated,
clearly we have a memory management Heisenbug.

The root-cause seems to be that the hw_params pointer is not
persistent. The soc-pcm code allocates the hw_params structure on the
stack, and passes it to the BE dailink hw_params and DAIs
hw_params. Saving such a pointer and reusing it later during the
.prepare stage cannot possibly work reliably, it's broken-by-design
since v5.10. It's astonishing that the problem was not seen earlier.

This simple fix will have to be back-ported to -stable, due to changes
to avoid the use of the get/set_dmadata routines this patch will only
apply on kernels older than v6.1.

Fixes: a5a0239c27fe ("soundwire: intel: reinitialize IP+DSP in .prepare(), but only when resuming")
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Ranjani Sridharan
Reviewed-by: Péter Ujfalusi
Signed-off-by: Bard Liao
Link: https://lore.kernel.org/r/20230321022642.1426611-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: intel: move bank switch routine to common intel_bus_common.c

2023-03-15T13:54:02+00:00

No functionality change, just moving the routines to a common file so
that they can be used for new hardware.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20230314015410.487311-11-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: intel: add abstraction for cmdsync check

2023-03-15T13:54:02+00:00

If we add one more callback, we can have common bank switch sequences
between old and new hardware: the only difference is where the CMDSYNC
register is located.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20230314015410.487311-10-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: intel: move bus common sequences to different file

2023-03-15T13:54:02+00:00

Now that the bus start/stop/clock_stop sequences use the ops, we can
move them to a different file to reuse them.

Note that we could in theory remove the abstraction for all those
sequences and directly call the functions in intel_auxdevice.c. To
allow for more flexibility and have means to special-case new
platforms, we decided to keep the abstraction. If in time it becomes
clear there is no benefit the abstraction will be simplified.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20230314015410.487311-9-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: intel: use indirection before moving bus start/stop sequences

2023-03-15T13:54:02+00:00

There was no benefit to using the existing abstraction, but since we
are going to move the code make sure we do use the ops.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20230314015410.487311-8-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: intel: add sync_arm/sync_go to ops

2023-03-15T13:54:02+00:00

The bus start/stop sequences can be reused between platforms if we add
a couple of new callbacks. In following patches the code will be moved to
a shared file.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20230314015410.487311-7-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: intel: simplify sync_go sequence

2023-03-15T13:54:02+00:00

In the existing code, the SHIM_SYNC::SYNC_GO bit is set, and the code
waits for it to return to zero.

That second wait part is just wrong: the SYNC_GO bit is *write-only* so
there's no way to know if it's cleared by hardware. The code works
because the value for a read-only bit is zero, but that's really just
luck.

Simplify the sequence to a plain read-modify-write.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20230314015410.487311-6-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: intel: remove useless abstraction

2023-03-15T13:54:01+00:00

PDM is supported in the hardware but never enabled: there are no known
PDM-based devices. We can directly call the PCM helper.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20230314015410.487311-5-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: intel: remove PDI-level restrictions on rates and formats

2023-03-15T13:54:01+00:00

This is not relevant and not aligned with hardware definitions. In
addition, we've tested higher resolution formats so this is ignored at
a higher level.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20230314015410.487311-4-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: intel: remove stale/misleading comment

2023-03-15T13:54:01+00:00

The PDIs don't really have a notion of rates and formats, only
channels are relevant.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20230314015410.487311-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul