Repository navigation
Conversation
The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: thesofproject#4083 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: thesofproject#4083 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: thesofproject#4083 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: thesofproject#4083 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
plbossart
changed the title
|
Hold for merge, pending information on IPC timeout reported by @Vamshigopal in #4083 |
|
Tested on a sof_rt5682 machine where #4083 is hit and this indeed seems to help: [ 13.507950] Headset: ASoC: dpcm_be_connect FE Headset BE SSP0-Codec, besubstream 0000000008fc2624 ... I didn't have #4085 included in the tested kernel. |
@plbossart do you mean that even with this PR #4085 is still needed? |
|
@ranj063 wrote:
I think #4085 should still be done, just to be more robust against mistakes in tplg/machdriver setup, although it's not as critical maybe anymore. |
Yes, that's what I meant. This PR fixes existing Chromebook solutions, but there may be other cases we missed or didn't test. PR #4085 is defensive programming that should be added in case the design assumptions are incorrect. I would still extend PR #4085 to deal with all the cases where we use an invalid substream, not just the cases that are known to generate an oops. |
5 participants
This PR is in addition to #4085. Instead of filtering out invalid BEs, this PR adds the missing dpcm_capture fields needed when the dailink is associated with a firmware-generated echo reference.
One objection is that we're adding capture support unconditionally, but the rule is always that the machine driver needs to support more options that what the topology exposes. When the topology makes use of capabilities not explicitly supported in the machine driver, bad things happen. Usually it's just a topology binding issue, but in this case it was kernel oopses due to an invalid configuration.