Skip to content

ASoC: Intel: sof_da7219_max98373: Add BE dailink for dmic16k - #1967

Merged
kv2019i merged 1 commit into
thesofproject:topic/sof-devfrom
yongzhi1:topic/sof-dev
Apr 1, 2020
Merged

kv2019i merged 1 commit into
thesofproject:topic/sof-devfrom
yongzhi1:topic/sof-dev

Conversation

@yongzhi1

Copy link
Copy Markdown

Add dmic16k BE dailink for keyword detection support, FE is
added in topology tplg file.

Signed-off-by: Yong Zhi yong.zhi@intel.com

Add dmic16k BE dailink for keyword detection support, FE is
added in topology tplg file.

Signed-off-by: Yong Zhi <yong.zhi@intel.com>

@kv2019i kv2019i left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @yongzhi1 ! We've had some longer debates on how the extra Dmic PCM should be labelled, but this is aligned with the most recently merged machine drivers, so seems good to me.

@kv2019i
kv2019i merged commit b8464d1 into thesofproject:topic/sof-dev Apr 1, 2020
marc-hb added a commit to marc-hb/linux that referenced this pull request Apr 7, 2020
checkpatch has a --subjective (a.k.a --strict) option that enables a
few additional "checks". These additional "--strict checks" are desired
but - as expected from their name - their output is likely to be
dismissed more frequently than other checkpatch issues. For that reason,
a relatively complex post-processing Jenkins change was made on the 22nd
November 2019. After that change, --strict checks were still run by
Jenkins however --strict-only failures were "downgraded" to a green
success. For a good example look at sof-ci/jenkins/pr-checkpatch and
continuous-integration/travis-ci/pr details in PR thesofproject#1967.

This small Travis PR is meant to be merged immediately after the REMOVAL
of that complex checkpatch post-processing in Jenkins, swapping who
dismisses strict-only failures and who doesn't.

This swap is not just about replacing about 50 lines of internal Jenkins
code with a couple of lines of visible code in travis and checkpatch:
after this swap, a green continuous-integration/travis-ci/pr success and
a red sof-ci/jenkins/pr-checkpatch failure can have only one meaning: a
strict-only failure. Before this swap, no combination on the github page
ever identifies a strict-only failure.

Of course, it would be easier to have a real "yellow" color instead of
running checkpatch twice and creatively mixing one green and one
red. Unfortunately, neither Travis nor github seem to support anytihng
besides red and green:

  travis-ci/travis-ci#4730
  https://developer.github.com/v3/repos/statuses/
  https://github-api.kohsuke.org/apidocs/org/kohsuke/
                                        github/GHCommitState.html

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants