ASoC: SOF: Intel: hda: allow operation without i915 by kv2019i · Pull Request #1731 · thesofproject/linux

kv2019i · 2020-01-17T14:27:43Z

Add support to configure HDA controller with external codec even if iDisp codec in i915 is not available.

This can happen for multiple reasons:
- internal graphics is disabled on the system
- i915 driver is not enabled in kernel or it fails to init
- i915 codec reports error in HDA codec probe
- HDA codec driver probe fails

Address all these scenarios, but keep using the same topology configuration still. In case failures occur, HDMI PCM nodes are created, but they will report error at open. No ALSA mixer controls are created.

Fixes: #1658

Note to @plbossart : this will conflict with "ASoC: SOF: Intel: refactor i915_get/put functions" that was sent to upstream last week. In case merging get delayed, you'll see this.

kv2019i · 2020-01-17T14:29:08Z

Draft only, I didn't manage to clean up fully yet, but this looks very promising. We can extend the HDA generic driver to these cases without needing a separate topology. Plus a big bonus, transient faults with i915 hw (like the recent afg problems), won't bring down the whole SOF stack, but only the HDMI part.

lyakh · 2020-01-20T08:17:02Z

+				skl_hda_be_dai_links[i].codecs->name =
+					"snd-soc-dummy";
+				skl_hda_be_dai_links[i].codecs->dai_name =
+					"snd-soc-dummy-dai";


If I understand correctly, skl_hda_be_dai_links[i].codecs is actually an array of skl_hda_be_dai_links[i].num_codecs elements. So, the above actually means skl_hda_be_dai_links[i].codecs[0] and it assumes that .num_codecs is at least 1. Maybe indeed this is a valid assumption, but it would be better to use an array representation instead of just a pointer and maybe add a comment, saying that array is guaranteed to have at least one element in it?

@lyakh Ack. I changed this for the "production version" and used the common macros instead.

kv2019i · 2020-01-20T13:50:58Z

Ready for review folks! I tested all the error scenarios with specially crafted error injection code.

kv2019i · 2020-01-20T14:03:05Z

+		if (!hda->i915_codec_enabled) {
+			dev_dbg(sdev->dev,
+				"iDisp hw present but no driver, ignoring\n");
+			return -ENOENT;


One thing I wondered about is should the device be unregistered here immediately in the error case. But I ended up not doing that. snd_hdac_ext_bus_device_remove() will clean up this device as well.

kv2019i · 2020-01-20T14:04:02Z

There's one checkpatch warning (shows up as a failure from Travis).

CHECK: Alignment should match open parenthesis
#41: FILE: sound/soc/intel/boards/skl_hda_dsp_generic.c:65:
+SND_SOC_DAILINK_DEF(dummy_codec,
+       DAILINK_COMP_ARRAY(COMP_CODEC("snd-soc-dummy", "snd-soc-dummy-dai")));

... but this is matching with existing usage of SND_SOC_DAILINK_DEF in ASoC, so kept it like this.

plbossart

see comments below

plbossart · 2020-01-21T16:45:38Z

+	if ((resp & 0xFFFF0000) == IDISP_VID_INTEL) {
+		if (!hda->i915_codec_enabled) {
+			dev_dbg(sdev->dev,
+				"iDisp hw present but no driver, ignoring\n");


it's more 'will be ignored'. There is nothing in this function that ignores the codec, you just return a negative value that will be handled in hda_codec_probe_bus

@plbossart hmm, I'll change this. but we do skip the codec driver probe later in the function, so first part of "ignoring" is already done in this function. but yeah, the info needs to be passed to controller side as well and that is done in the parent, so point taken.

@plbossart "will be ignored" didn't fit 80-chars, so I left ", ignoring" part out.. not adding value

kv2019i · 2020-01-22T12:14:00Z

v3 uploaded: addressed Pierre's feedback to code comments, no other changes compared to v2

kv2019i · 2020-02-03T08:17:55Z

@lyakh @keyonjie @ranj063 please review, this is still waiting for a second approval

lgirdwood · 2020-02-03T10:17:11Z

 					HDAC_DAI_COUNT + i];
 		}
-	} else if (codec_count == 2 && codec_mask & IDISP_CODEC_MASK) {
+	} else if (codec_count <= 2) {


minor - why do we <= 2 codecs important here ?

lgirdwood · 2020-02-03T10:19:14Z

 				 hda_mach->drv_name);

-			if (codec_num == 1)
+			if (codec_num == 1 && HDA_IDISP_CODEC(bus->codec_mask))


minor again, not following here why codec count is important. previous author should have commented this.

plbossart

Minor change suggested so that the cases we support in the machine driver are crystal-clear
Thanks @kv2019i

kv2019i · 2020-02-05T12:34:15Z

I will let #1764 go in first and I will then rebase this one.

plbossart · 2020-02-05T17:34:24Z

I will let #1764 go in first and I will then rebase this one.

#1764 merged

kv2019i · 2020-02-10T11:31:37Z

I've addressed the comments in my local branch, but will wait and not upload until #1767 is merged via upstream (there's a conflict).

kv2019i · 2020-02-17T09:16:10Z

One remaining issues with SOF module load/unload with this patchset and latest sof-dev, will debug this today.

kv2019i · 2020-02-17T15:44:41Z

@lgirdwood @plbossart Now updated to address your comments.

plbossart

Something's fishy with the mask/count code?

plbossart · 2020-02-18T17:56:17Z

+		return -EINVAL;

-	if (codec_count == 1 && codec_mask & IDISP_CODEC_MASK) {
+	if (codec_count == idisp_count) {


Humm, confused...

idisp_count is either 0 or 0x4.

did you mean idisp_count = hweight_long(codec_mask & IDISP_CODEC_MASK) ?

@plbossart Gah :(, thanks Pierre for catching this. I also messed up in testing as I thought I had covered this case, but I didn't as this is obviously wrong. Going back, the checks still looked too complicated as well. I now updated the 3rd try with s/disp_count/idisp_mask/ and added more comments to further clarify that we are handling two separate cases of topologies here. Hopefully now clear. Tested scenarios on CFL as well.

Extend the generic HDA driver to support systems where iDisp/HDMI audio codecs are disabled for some reason. Switch codecs to SoC dummy in the affected DAI links. This allows to reuse existing topologies for this case. BugLink: thesofproject#1658 BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1163677 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206085 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

Add support to configure the HDA controller with an external HDA codec even if iDisp codec in i915 is not available. This can happen for multiple reasons: - internal graphics is disabled on the system - i915 driver is not enabled in kernel or it fails to init - i915 codec reports error in HDA codec probe - HDA codec driver probe fails Address all these scenarios, but keep using the existing topology. In case failures occur, HDMI PCM nodes are created, but they will report error if application tries to use them. No ALSA mixer controls are created. If the external HDA codec init fails as well, SOF probe will return error as before. BugLink: thesofproject#1658 BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1163677 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206085 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

plbossart

Thanks @kv2019i

Should
a) merge this
b) send upstream directly
c) merge upstream stuff then resolve conflicts then send upstream?

kv2019i · 2020-02-19T11:36:23Z

@plbossart wrote:

Should
a) merge this
b) send upstream directly
c) merge upstream stuff then resolve conflicts then send upstream?

Let's take (c). I'll add your reviewed-by tags and send directly. This patch is not critical to have in sof-dev (but is critical for people with affected hw) and I don't have any follow-up patches to these parts of the code, so might as well sent to the list.

kv2019i · 2020-02-20T17:15:03Z

Sent to upstream, let's merge this via upstream. Keeping open until merged upstream.

kv2019i · 2020-03-19T15:17:50Z

Merged upstream and in sof-dev as well (via rebase).

kv2019i requested review from plbossart and ranj063 January 17, 2020 14:27

kv2019i requested review from keyonjie and lyakh January 17, 2020 14:29

lyakh reviewed Jan 20, 2020

View reviewed changes

kv2019i force-pushed the topic/hda-without-i915 branch from a2246bb to 83a99d4 Compare January 20, 2020 13:47

kv2019i marked this pull request as ready for review January 20, 2020 13:49

kv2019i requested a review from lgirdwood as a code owner January 20, 2020 13:49

kv2019i requested a review from lyakh January 20, 2020 13:50

kv2019i commented Jan 20, 2020

View reviewed changes

lyakh reviewed Jan 20, 2020

View reviewed changes

Comment thread sound/soc/intel/boards/skl_hda_dsp_generic.c

plbossart reviewed Jan 21, 2020

View reviewed changes

kv2019i force-pushed the topic/hda-without-i915 branch from 83a99d4 to a6da130 Compare January 22, 2020 12:13

kv2019i requested review from lyakh and plbossart January 22, 2020 12:14

plbossart approved these changes Jan 24, 2020

View reviewed changes

lgirdwood previously approved these changes Feb 3, 2020

View reviewed changes

plbossart requested changes Feb 3, 2020

View reviewed changes

Comment thread sound/soc/intel/boards/skl_hda_dsp_generic.c

kv2019i mentioned this pull request Feb 5, 2020

[RFC] ASoC: Intel: boards: hda_dsp_common: switch to use config item _HDA_L… #1680

Closed

kv2019i mentioned this pull request Feb 11, 2020

ASoC: Intel: sof_pcm512x: make HDMI optional for all platforms #1777

Merged

kv2019i dismissed lgirdwood’s stale review via 378af3e February 17, 2020 15:43

kv2019i force-pushed the topic/hda-without-i915 branch from a6da130 to 378af3e Compare February 17, 2020 15:43

kv2019i requested review from lgirdwood and plbossart February 17, 2020 15:44

kv2019i force-pushed the topic/hda-without-i915 branch from 378af3e to 6574cb7 Compare February 18, 2020 11:40

plbossart requested changes Feb 18, 2020

View reviewed changes

kv2019i added 2 commits February 18, 2020 21:11

kv2019i force-pushed the topic/hda-without-i915 branch from 6574cb7 to ba0aba7 Compare February 18, 2020 19:12

ranj063 reviewed Feb 18, 2020

View reviewed changes

Comment thread sound/soc/intel/boards/skl_hda_dsp_generic.c

ranj063 approved these changes Feb 18, 2020

View reviewed changes

plbossart approved these changes Feb 18, 2020

View reviewed changes

kv2019i added the upstream Patch has been sent to upstream (e.g. alsa-devel) label Feb 20, 2020

kv2019i closed this Mar 19, 2020

Uh oh!

Conversation

kv2019i commented Jan 17, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kv2019i commented Jan 17, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kv2019i commented Jan 20, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kv2019i commented Jan 20, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kv2019i commented Jan 22, 2020

Uh oh!

kv2019i commented Feb 3, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kv2019i commented Feb 5, 2020

Uh oh!

plbossart commented Feb 5, 2020

Uh oh!

kv2019i commented Feb 10, 2020

Uh oh!

kv2019i commented Feb 17, 2020

Uh oh!

kv2019i commented Feb 17, 2020

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

kv2019i commented Feb 19, 2020

Uh oh!

kv2019i commented Feb 20, 2020

Uh oh!

kv2019i commented Mar 19, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

kv2019i commented Jan 17, 2020 •

edited

Loading

kv2019i commented Jan 20, 2020 •

edited

Loading