linux-toradex.git/drivers/soundwire/cadence_master.c, branch v5.18

soundwire: intel: remove PDM support

2021-12-24T14:06:50+00:00

While the hardware supports PDM streams, this capability has never
been tested or enabled on any product, so this is dead-code. Let's
remove all this.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Péter Ujfalusi 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Acked-By: Vinod Koul 
Link: https://lore.kernel.org/r/20211224021034.26635-8-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown

soundwire: cadence: do not extend reset delay

2021-08-23T12:10:34+00:00

The duration of the hw_reset is defined as 4096 cycles. The Cadence IP
allows for an additional delay which doesn't seem necessary in
practice: the actual reset sequence duration is defined by the sync_go
mechanism, not by the IP itself.

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

soundwire: cadence: override PDI configurations to create loopback

2021-08-02T05:38:22+00:00

When we set a source PDI, the target PDI parameters will be overridden
by the source register values. The loopback streams can be
independently enabled on each link.

While the loopback source and target can be configured before any
stream is active on each link, the loopback stream should only be
prepared/triggered when the playback stream is prepared. Otherwise all
registers might be programmed to their reset values and the loopback
will not succeed. The SoundWire bus driver currently does not allow
two streams to be triggered at the same time, so the playback will
have to be started first, and later the loopback.

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

soundwire: cadence: add debugfs interface for PDI loopbacks

2021-08-02T05:38:22+00:00

For debug, it's interesting to create a loopback stream for each link
and use debugfs to set a source and target PDI. The target PDI would
need to be an RX port and use the same register configurations as the
source PDI. This capability allows e.g. for the headphone playback
stream to be snooped on the headset capture stream, or alternatively
for the addition of a dedicated loopback stream, in addition of
regular capture for that link.

This patch only adds the debugfs part, the port/PDI handling will be
handled in the next patches.

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

soundwire: cadence: add paranoid check on self-clearing bits

2021-08-02T03:49:45+00:00

The Cadence IP exposes a small number of self-clearing bits in
the MCP_CONTROL and MCP_CONFIG_UPDATE registers.

We currently do not check that those bits are indeed cleared,
e.g. during resume operations. That could lead to resuming peripheral
devices too early.

In addition, if we happen to read these registers, update one of the
fields and write the register back, we may be writing stale data that
might have been cleared in hardware. These sort of race conditions
could lead to e.g. doing a hw_reset twice or stopping a clock that
just restarted. There is no clear way of avoiding these potential race
conditions other than making sure that these registers fields are
cleared before any read-modify-write sequence. If we detect this sort
of errors, we only log them since there is no clear recovery
possible. The only way out is likely to restart the IP with a
suspend/resume cycle.

Note that the checks are performed before updating the registers, as
well as after the Intel 'sync go' sequence in multi-link mode. That
should cover both the start and end of suspend/resume hardware
configurations. The Multi-Master mode gates the configuration updates
until the 'sync go' signal is asserted, so we only check on init and
after the end of the 'sync go' sequence.

The duration of the usleep_range() was defined by the GSYNC frequency
used in multi-master mode. With a 4kHz frequency, any configuration
change might be deferred by up to 250us. Extending the range to
1000-1500us should guarantee that the configuration change is
completed without any significant impact on the overall resume
time.

Suggested-by: Bard Liao 
Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20210714051349.13064-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: cadence: Remove ret variable from sdw_cdns_irq()

2021-07-22T14:17:35+00:00

The ret is not used in the interrupt handler, it is just returned without
any condition or change.
We can return the IRQ_HANDLED directly.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Guennadi Liakhovetski 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20210714015555.17685-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: cadence_master: always set CMD_ACCEPT

2021-05-11T12:20:33+00:00

The Cadence IP can be configured in two different ways to deal with
CMD_IGNORED replies to broadcast commands. The CMD_ACCEPT bitfield
controls whether the command is discarded or if the IP proceeds with
the change (typically a bank switch or clock stop command).

The existing code seems to be inconsistent:
a) For some historical reason, we set this CMD_ACCEPT bitfield during
the initialization, but we don't during a resume from a clock-stoppped
state.
b) In addition, the loop used in the clock-stop sequence is quite
racy, it's possible that a device has lost sync but it's still tagged
as ATTACHED.
c) If somehow a Device loses sync and is unable to ack a broadcast
command, we do not have an error handling mechanism anyways. The IP
should go ahead and let the Device regain sync at a later time.

Make sure the CMD_ACCEPT bit is always set.

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

soundwire: cadence: only prepare attached devices on clock stop

2021-03-30T09:06:11+00:00

We sometimes see COMMAND_IGNORED responses during the clock stop
sequence. It turns out we already have information if devices are
present on a link, so we should only prepare those when they
are attached.

In addition, even when COMMAND_IGNORED are received, we should still
proceed with the clock stop. The device will not be prepared but
that's not a problem.

The only case where the clock stop will fail is if the Cadence IP
reports an error (including a timeout), or if the devices throw a
COMMAND_FAILED response.

BugLink: https://github.com/thesofproject/linux/issues/2621
Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Reviewed-by: Guennadi Liakhovetski 
Signed-off-by: Bard Liao 
Link: https://lore.kernel.org/r/20210323013707.21455-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: cadence_master: fix kernel-doc

2021-03-30T07:00:01+00:00

v5.12-rc1 flags new warnings with make W=1, fix missing or broken
function descriptors.

drivers/soundwire/cadence_master.c:914: warning: expecting prototype
for To update slave status in a work since we will need to
handle(). Prototype was for cdns_update_slave_status_work() instead

drivers/soundwire/cadence_master.c:976: warning: expecting prototype
for sdw_cdns_enable_slave_interrupt(). Prototype was for
cdns_enable_slave_interrupts() instead

Signed-off-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20210301174714.117172-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Vinod Koul

soundwire: cadence: add missing \n in dev_err()

2021-03-23T06:49:53+00:00

We fixed a lot of warnings in 2019 but the magic of copy-paste keeps
adding new ones...

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