[PATCH v2 0/3] soundwire: clear bus clash/parity interrupt before the mask is enabled
The SoundWire specification allows a Slave device to report a bus clash or parity error with the in-band interrupt mechanism. Unfortunately, on some platforms, these errors are randomly reported and don't seem to be valid. This series suggests the addition of a Master level quirk to discard such interrupts. The quirk should in theory have been added at the Slave level, but since the problem was detected with different generations of Slave devices it's hard to point to a specific IP. The problem might also be board-dependent and hence dealing with a Master quirk is simpler.
v2: - Reorder the patches sequence. - Add comments about each quirk. - Use u64 quirks.
Bard Liao (3): soundwire: add master quirks for bus clash and parity soundwire: bus: handle master quirks for bus clash and parity soundwire: intel: add master quirks for bus clash and parity
drivers/soundwire/bus.c | 39 +++++++++++++++++++++++++++++++++++ drivers/soundwire/intel.c | 3 +++ include/linux/soundwire/sdw.h | 22 ++++++++++++++++++++ 3 files changed, 64 insertions(+)
Currently quirks are only allowed for Slave devices. This patch describes the need for two quirks at the Master level.
a) bus clash The SoundWire specification allows a Slave device to report a bus clash with the in-band interrupt mechanism when it detects a conflict while driving a bitSlot it owns. This can be a symptom of an electrical conflict or a programming error, and it's vital to detect reliably.
Unfortunately, on some platforms, bus clashes are randomly reported by Slave devices after a bus reset, with an interrupt status set even before the bus clash interrupt is enabled. These initial spurious interrupts are not relevant and should optionally be filtered out, while leaving the interrupt mechanism enabled to detect 'true' issues.
This patch suggests the addition of a Master level quirk to discard such interrupts. The quirk should in theory have been added at the Slave level, but since the problem was detected with different generations of Slave devices it's hard to point to a specific IP. The problem might also be board-dependent and hence dealing with a Master quirk is simpler.
b) parity
Additional tests on a new platform with the Maxim 98373 amplifier showed a rare case where the parity interrupt is also thrown on startup, at the same time as bus clashes. This issue only seems to happen infrequently and was only observed during suspend-resume stress tests while audio is streaming. We could make the problem go away by adding a Slave-level quirk, but there is no evidence that the issue is actually a Slave problem: the parity is provided by the Master, which could also set an invalid parity in corner cases.
BugLink: https://github.com/thesofproject/linux/issues/2578 BugLink: https://github.com/thesofproject/linux/issues/2533
Co-developed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Bard Liao yung-chuan.liao@linux.intel.com Reviewed-by: Guennadi Liakhovetski guennadi.liakhovetski@linux.intel.com --- include/linux/soundwire/sdw.h | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h index d08039d65825..25f2a14e2e83 100644 --- a/include/linux/soundwire/sdw.h +++ b/include/linux/soundwire/sdw.h @@ -405,6 +405,7 @@ struct sdw_slave_prop { * command * @mclk_freq: clock reference passed to SoundWire Master, in Hz. * @hw_disabled: if true, the Master is not functional, typically due to pin-mux + * @quirks: bitmask identifying optional behavior beyond the scope of the MIPI specification */ struct sdw_master_prop { u32 revision; @@ -421,8 +422,29 @@ struct sdw_master_prop { u32 err_threshold; u32 mclk_freq; bool hw_disabled; + u64 quirks; };
+/* Definitions for Master quirks */ + +/* + * In a number of platforms bus clashes are reported after a hardware + * reset but without any explanations or evidence of a real problem. + * The following quirk will discard all initial bus clash interrupts + * but will leave the detection on should real bus clashes happen + */ +#define SDW_MASTER_QUIRKS_CLEAR_INITIAL_CLASH BIT(0) + +/* + * Some Slave devices have known issues with incorrect parity errors + * reported after a hardware reset. However during integration unexplained + * parity errors can be reported by Slave devices, possibly due to electrical + * issues at the Master level. + * The following quirk will discard all initial parity errors but will leave + * the detection on should real parity errors happen. + */ +#define SDW_MASTER_QUIRKS_CLEAR_INITIAL_PARITY BIT(1) + int sdw_master_read_prop(struct sdw_bus *bus); int sdw_slave_read_prop(struct sdw_slave *slave);
On 02-03-21, 16:27, Bard Liao wrote:
Currently quirks are only allowed for Slave devices. This patch describes the need for two quirks at the Master level.
a) bus clash The SoundWire specification allows a Slave device to report a bus clash with the in-band interrupt mechanism when it detects a conflict while driving a bitSlot it owns. This can be a symptom of an electrical conflict or a programming error, and it's vital to detect reliably.
Unfortunately, on some platforms, bus clashes are randomly reported by Slave devices after a bus reset, with an interrupt status set even before the bus clash interrupt is enabled. These initial spurious interrupts are not relevant and should optionally be filtered out, while leaving the interrupt mechanism enabled to detect 'true' issues.
This patch suggests the addition of a Master level quirk to discard such interrupts. The quirk should in theory have been added at the Slave level, but since the problem was detected with different generations of Slave devices it's hard to point to a specific IP. The problem might also be board-dependent and hence dealing with a Master quirk is simpler.
b) parity
Additional tests on a new platform with the Maxim 98373 amplifier showed a rare case where the parity interrupt is also thrown on startup, at the same time as bus clashes. This issue only seems to happen infrequently and was only observed during suspend-resume stress tests while audio is streaming. We could make the problem go away by adding a Slave-level quirk, but there is no evidence that the issue is actually a Slave problem: the parity is provided by the Master, which could also set an invalid parity in corner cases.
BugLink: https://github.com/thesofproject/linux/issues/2578 BugLink: https://github.com/thesofproject/linux/issues/2533
Please do not add blank lines here
Co-developed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Bard Liao yung-chuan.liao@linux.intel.com Reviewed-by: Guennadi Liakhovetski guennadi.liakhovetski@linux.intel.com
include/linux/soundwire/sdw.h | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h index d08039d65825..25f2a14e2e83 100644 --- a/include/linux/soundwire/sdw.h +++ b/include/linux/soundwire/sdw.h @@ -405,6 +405,7 @@ struct sdw_slave_prop {
- command
- @mclk_freq: clock reference passed to SoundWire Master, in Hz.
- @hw_disabled: if true, the Master is not functional, typically due to pin-mux
*/
- @quirks: bitmask identifying optional behavior beyond the scope of the MIPI specification
struct sdw_master_prop { u32 revision; @@ -421,8 +422,29 @@ struct sdw_master_prop { u32 err_threshold; u32 mclk_freq; bool hw_disabled;
- u64 quirks;
};
+/* Definitions for Master quirks */
+/*
- In a number of platforms bus clashes are reported after a hardware
- reset but without any explanations or evidence of a real problem.
- The following quirk will discard all initial bus clash interrupts
- but will leave the detection on should real bus clashes happen
- */
+#define SDW_MASTER_QUIRKS_CLEAR_INITIAL_CLASH BIT(0)
+/*
- Some Slave devices have known issues with incorrect parity errors
- reported after a hardware reset. However during integration unexplained
- parity errors can be reported by Slave devices, possibly due to electrical
- issues at the Master level.
- The following quirk will discard all initial parity errors but will leave
- the detection on should real parity errors happen.
- */
+#define SDW_MASTER_QUIRKS_CLEAR_INITIAL_PARITY BIT(1)
int sdw_master_read_prop(struct sdw_bus *bus); int sdw_slave_read_prop(struct sdw_slave *slave);
-- 2.17.1
Add optional interrupt status read/clear if the master quirks are set.
In the case of the parity, the master quirk is only applied if the Slave doesn't already have a parity-related quirk.
Co-developed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Bard Liao yung-chuan.liao@linux.intel.com Reviewed-by: Guennadi Liakhovetski guennadi.liakhovetski@linux.intel.com --- drivers/soundwire/bus.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index 46885429928a..04eb879de145 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -1253,6 +1253,7 @@ static int sdw_slave_set_frequency(struct sdw_slave *slave) static int sdw_initialize_slave(struct sdw_slave *slave) { struct sdw_slave_prop *prop = &slave->prop; + int status; int ret; u8 val;
@@ -1260,6 +1261,44 @@ static int sdw_initialize_slave(struct sdw_slave *slave) if (ret < 0) return ret;
+ if (slave->bus->prop.quirks & SDW_MASTER_QUIRKS_CLEAR_INITIAL_CLASH) { + /* Clear bus clash interrupt before enabling interrupt mask */ + status = sdw_read_no_pm(slave, SDW_SCP_INT1); + if (status < 0) { + dev_err(&slave->dev, + "SDW_SCP_INT1 (BUS_CLASH) read failed:%d\n", status); + return status; + } + if (status & SDW_SCP_INT1_BUS_CLASH) { + dev_warn(&slave->dev, "Bus clash detected before INT mask is enabled\n"); + ret = sdw_write_no_pm(slave, SDW_SCP_INT1, SDW_SCP_INT1_BUS_CLASH); + if (ret < 0) { + dev_err(&slave->dev, + "SDW_SCP_INT1 (BUS_CLASH) write failed:%d\n", ret); + return ret; + } + } + } + if ((slave->bus->prop.quirks & SDW_MASTER_QUIRKS_CLEAR_INITIAL_PARITY) && + !(slave->prop.quirks & SDW_SLAVE_QUIRKS_INVALID_INITIAL_PARITY)) { + /* Clear parity interrupt before enabling interrupt mask */ + status = sdw_read_no_pm(slave, SDW_SCP_INT1); + if (status < 0) { + dev_err(&slave->dev, + "SDW_SCP_INT1 (PARITY) read failed:%d\n", status); + return status; + } + if (status & SDW_SCP_INT1_PARITY) { + dev_warn(&slave->dev, "PARITY error detected before INT mask is enabled\n"); + ret = sdw_write_no_pm(slave, SDW_SCP_INT1, SDW_SCP_INT1_PARITY); + if (ret < 0) { + dev_err(&slave->dev, + "SDW_SCP_INT1 (PARITY) write failed:%d\n", ret); + return ret; + } + } + } + /* * Set SCP_INT1_MASK register, typically bus clash and * implementation-defined interrupt mask. The Parity detection
Now that we have declarations and bus support, add quirks for Intel platforms.
Co-developed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Bard Liao yung-chuan.liao@linux.intel.com Reviewed-by: Guennadi Liakhovetski guennadi.liakhovetski@linux.intel.com --- drivers/soundwire/intel.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index a2d5cdaa9998..c1fdc85d0a74 100644 --- a/drivers/soundwire/intel.c +++ b/drivers/soundwire/intel.c @@ -1286,6 +1286,9 @@ static int sdw_master_read_intel_prop(struct sdw_bus *bus) if (quirk_mask & SDW_INTEL_QUIRK_MASK_BUS_DISABLE) prop->hw_disabled = true;
+ prop->quirks = SDW_MASTER_QUIRKS_CLEAR_INITIAL_CLASH | + SDW_MASTER_QUIRKS_CLEAR_INITIAL_PARITY; + return 0; }
On 02-03-21, 16:27, Bard Liao wrote:
The SoundWire specification allows a Slave device to report a bus clash or parity error with the in-band interrupt mechanism. Unfortunately, on some platforms, these errors are randomly reported and don't seem to be valid. This series suggests the addition of a Master level quirk to discard such interrupts. The quirk should in theory have been added at the Slave level, but since the problem was detected with different generations of Slave devices it's hard to point to a specific IP. The problem might also be board-dependent and hence dealing with a Master quirk is simpler.
I think this is fine approach to deal with quirks... Controllers can set the quirk as required. I have fixed up blank line in patch 1 and applied
participants (2)
-
Bard Liao
-
Vinod Koul