ASOC: SOF: choose hda machine driver if hda codes detected #508

RanderWang · 2019-01-07T07:01:37Z

It is ugly in pci probing function to check hda for machine driver. Now
select hda machine driver after hda codec has been detected. And
And select nocodec driver if no hda codec is detected and no I2S
machine driver is applied.

This fixes #284

RanderWang · 2019-01-07T07:45:02Z

Test it on hda and i2s platforms

plbossart

Nice try but not what I had in mind.
What this patch does is add duplicate code to check if there are HDAudio codecs. We'd want to do this as part of the probe without new code introduced.

RanderWang · 2019-01-08T02:06:23Z

@plbossart Do you mean to do it in sof_dsp probe? I submitted a PR before(#321), you comment was:

The ask is that we can have a single kernel with HDaudio compiled in, and the behavior is as follows
a. try to find an ACPI ID and create the relevant machine driver
b. if this fails, check if there are HDAudio codecs. if HDaudio + iDISP are found, use the generic HDaudio machine driver.
c1. if nothing is detected fall back to nocodec.
c2. If only iDISP is found, either fallback to a nocodec+iDISP configuration or to a simple iDISP configuration if nocodec is not selected.

plbossart · 2019-01-08T05:43:45Z

@plbossart Do you mean to do it in sof_dsp probe? I submitted a PR before(#321), you comment was:

The ask is that we can have a single kernel with HDaudio compiled in, and the behavior is as follows
a. try to find an ACPI ID and create the relevant machine driver
b. if this fails, check if there are HDAudio codecs. if HDaudio + iDISP are found, use the generic HDaudio machine driver.
c1. if nothing is detected fall back to nocodec.
c2. If only iDISP is found, either fallback to a nocodec+iDISP configuration or to a simple iDISP configuration if nocodec is not selected.

My point was to try and to the codec probe earlier. that didn't mean duplicating code.

RanderWang · 2019-01-08T08:00:54Z

Get it, I will try to make it.

RanderWang · 2019-01-09T07:01:20Z

update my PR.
(1) move hda codec detection to hda_codec.c
(2) share the function in sof

Thanks!

plbossart

the code looks good but this PR has a couple of issues
a) the error flow needs to be reworked completely, it's obviously broken
b) it results in some inits being done multiple times. That's not good, we need to have a simple call flow where we don't repeat things and add complexity.
c) I would really prefer it if we didn't have an HDaudio-specific flow and API added. The code feels like a hack if we don't use an abstraction or the normal flow.

plbossart · 2019-01-09T16:26:07Z

sound/soc/sof/sof-pci-dev.c

that is still adding a new step and new API to the core that's HDaudio specific. You will also do things multiple times since the "bus" variable is local and all inits are gone once you leave the scope of this block.

yes, you mean: only initialize hda one time in pci probe and pass it to sof core ?
I will try to make it.

plbossart · 2019-01-09T16:26:44Z

sound/soc/sof/intel/hda-codec.c

don't we have a helper for this already?

yes, I will refine it

plbossart · 2019-01-09T16:27:18Z

sound/soc/sof/intel/hda-codec.c

this should be an error.

yes, I will refine it

plbossart · 2019-01-09T16:28:08Z

sound/soc/sof/intel/hda-codec.c

Bam. your error flow did not turn i915 power off. this needs to be reworked.

yes, I will refine it

plbossart · 2019-01-09T16:29:58Z

sound/soc/sof/intel/hda-codec.c

this should be part of the error flow.
Also this means you will initialize the i912 connection two times, and it's not clear to me why this was needed if the first step is successful.

yes, I will refine it

plbossart · 2019-01-10T03:50:25Z

On 1/9/19 8:28 PM, RanderWang wrote: ***@***.**** commented on this pull request. ------------------------------------------------------------------------ In sound/soc/sof/sof-pci-dev.c <#508 (comment)>: > @@ -207,14 +207,13 @@ static int sof_pci_probe(struct pci_dev *pci, mach = snd_soc_acpi_find_machine(desc->machines); #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA) if (!mach) { - dev_warn(dev, "No matching ASoC machine driver found - falling back to HDA codec\n"); - mach = snd_soc_acpi_intel_hda_machines; - mach->sof_fw_filename = desc->nocodec_fw_filename; - - /* - * TODO: we need to find a way to check if codecs are actually - * present - */ + struct hdac_bus bus; + + if (hda_codec_detect(pci, &bus, FALSE) > 0) { yes, you mean: only initialize hda one time in pci probe and pass it to sof core ? I will try to make it.

No. This is just moving things around, what I really would like is that the codec_mask is available before the machine driver selection is made.

RanderWang · 2019-01-10T09:49:32Z

Update my PR. Now hda codec is initialized only one time.

Sorry to make CI failed, but it works in my local machine. Today I can't fix it. This PR is just for review.

plbossart · 2019-01-10T18:16:40Z

to be clearer, i'd like the detection to rely on the abstraction that exists for SOF. calling directly a low-level function directly from sof-pci-dev isn't exactly aligned with what we do. It introduces a short-cut that isn't elegant at all. maybe this means we need a .hardware_detect before sof_probe indeed but there's no reason to have a low-level bypass only for the hdaudio case.

keyonjie · 2019-01-11T06:09:34Z

c) I would really prefer it if we didn't have an HDaudio-specific flow and API added. The code feels like a hack if we don't use an abstraction or the normal flow.

@plbossart I agree that those HDaudio-specific code in sof-pci-dev.c looks hack. Shall we postpone the machine driver selection to sof_probe():

static int sof_probe(struct platform_device *pdev)
{
...
	/* probe the DSP hardware */
	ret = snd_sof_probe(sdev);
...
//Let's move the HDA/nocodec machine driver selection here?
...

	/* register machine driver, pass machine info as pdata */
	plat_data->pdev_mach =
		platform_device_register_data(sdev->dev, drv_name,
					      PLATFORM_DEVID_NONE, mach, size);
...
}

plbossart · 2019-01-11T16:55:31Z

On 1/11/19 12:09 AM, Keyon wrote: c) I would really prefer it if we didn't have an HDaudio-specific flow and API added. The code feels like a hack if we don't use an abstraction or the normal flow. @plbossart <https://github.com/plbossart> I agree that those HDaudio-specific code in sof-pci-dev.c looks hack. Shall we postpone the machine driver selection to sof_probe(): |static int sof_probe(struct platform_device *pdev) { ... /* probe the DSP hardware */ ret = snd_sof_probe(sdev); ... //Let's move the HDA/nocodec machine driver selection here? ...|

|I initially thought this was a good idea but this would also add an HDAudio specific test in the middle of the most common piece of code. Let's think a bit more on this.|

…

|/* register machine driver, pass machine info as pdata */ plat_data->pdev_mach = platform_device_register_data(sdev->dev, drv_name, PLATFORM_DEVID_NONE, mach, size); ... } | — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#508 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGIa0zo1EkSet14xZrFZOkX5BqHuhnnks5vCCqegaJpZM4Zy93N>.

keyonjie · 2019-01-14T01:49:31Z

On 1/11/19 12:09 AM, Keyon wrote: c) I would really prefer it if we didn't have an HDaudio-specific flow and API added. The code feels like a hack if we don't use an abstraction or the normal flow. @plbossart https://github.com/plbossart I agree that those HDaudio-specific code in sof-pci-dev.c looks hack. Shall we postpone the machine driver selection to sof_probe(): |static int sof_probe(struct platform_device pdev) { ... / probe the DSP hardware */ ret = snd_sof_probe(sdev); ... //Let's move the HDA/nocodec machine driver selection here? ...|
|I initially thought this was a good idea but this would also add an HDAudio specific test in the middle of the most common piece of code. Let's think a bit more on this.|

How about adding an general ops there to do the hda codec_mask check and matched machine update inside it:

/* machine selection finalize */
static inline int snd_sof_machine_finalize(struct snd_sof_dev *sdev)
{
	if (sof_ops(sdev)->machine_finalize)
		return sof_ops(sdev)->machine_finalize(sdev);

	return 0;
}

RanderWang · 2019-01-14T09:49:20Z

@plbossart @keyonjie I submit a prototype of keyon's idea and test it on WHL.
Thanks!

plbossart

I like this idea, it's simple enough. That said, this will not work with e.g. Up2 with HDMI enabled, so the criterion to select the HDAudio machine driver needs to be modified, e.g. with the codec_mask that has at bitfield 2 set (0x4) and possibly one additional field for the HDaudio codec.

plbossart · 2019-01-14T18:50:05Z

sound/soc/sof/intel/hda.c

this looks wrong. You are overriding the machine already selected based on ACPI ID. this should only happen if there was no machine found earlier.

We don't set .sof_fw_filename in hda_machines, I think that's why we need set it above.
Please see below:

struct snd_soc_acpi_mach snd_soc_acpi_intel_hda_machines[] = { { /* .id is not used in this file */ .drv_name = "skl_hda_dsp_generic", /* .fw_filename is dynamically set in skylake driver */ /* .sof_fw_filename is dynamically set in sof/intel driver */ .sof_tplg_filename = "intel/sof-hda-generic.tplg", ... }, {}, };

We actually use same FW filename for different machines with same chip, e.g. "sof-apl.ri" for all I2S, HDA, nocodec machines.

struct sof_dev_desc { ... /* defaults for no codec mode */ const char *nocodec_fw_filename; const char *nocodec_tplg_filename; ... };

So, how about rename struct sof_dev_desc.nocodec_fw_filename to "sof_dev_desc.default_fw_filename"?

struct sof_dev_desc { ... /* default binary names */ const char *default_fw_filename; const char *nocodec_tplg_filename; ... };

And then, we can do it like this:

} else { mach = snd_soc_acpi_intel_hda_machines; if (!mach->sof_fw_filename) /* use default fw name */ mach->sof_fw_filename = pdata->desc->default_fw_filename;

Another option is get sof_fw_filename from other I2S machine, but this is still not natural

mach = snd_soc_acpi_intel_hda_machines; mach->sof_fw_filename = pdata->desc->machines[0].sof_fw_filename; pdata->machine = mach;

No. The feedback was on the No. The feedback was mach = snd_soc_acpi_intel_hda_machines;
You essentially remove all capability of using I2S codecs if there is HDMI detected.
Please test on Up2 w/ Hifiberry.

No. The feedback was on the No. The feedback was mach = snd_soc_acpi_intel_hda_machines;
You essentially remove all capability of using I2S codecs if there is HDMI detected.
Please test on Up2 w/ Hifiberry.

ah, right, good catch. @RanderWang we should do this codec_mask checking and pdata->machine updating only at "pdata->machine == NULL" case.

Now I will only use hda machine driver if both hdac codecs and hdmi are detected. This is a advice from pierre. I also want to do this. And I also struggle about : if only hdmi is detected, to use hda machine , which supports this, or nocodec machine ? And hdmi could be detected with I2S machine. So I prefer to use hda machine only hdac codecs and hdmi codec are detected.

plbossart · 2019-01-14T18:53:04Z

sound/soc/sof/sof-pci-dev.c

you need to check the error flow. now there is no longer an error when no machine driver is found, so this is a new flow which needs to be checked

yes, I will refine it

I check the error flow and find that there is only one error label release_regions which is shared by many error checks. I will check the status in sof-probe and release_regions there.

@plbossart I check machine in sof core and sof_probe would be failed if machine is NULL. Now the flow would be sof_probe failed -> pci_probe failed. I know this issue you are working with @libinyang @ranj063, so it is a generic issue.

plbossart · 2019-01-14T18:54:27Z

sound/soc/sof/nocodec.c

rename as sof_nocodec_bes_setup then?

ranj063 · 2019-01-16T04:31:17Z

@RanderWang @plbossart a question unrelated to this PR but related to the choice of machine drivers in general.

For boards like WHL RVP without any codecs, can we just test HDMI playback with SOF and if so which machine driver should be chosen in this case?

RanderWang · 2019-01-16T05:50:08Z

For boards like WHL RVP without any codecs, can we just test HDMI playback with SOF and if so which machine driver should be chosen in this case?

Actually, there is a hda codec (ALC700) on WHL RVP. Just test HDMI is not enough. For example
for cases: I2S + HDMI, HDA + HDMI, or only HDMI (nocodec mode).

RanderWang · 2019-01-16T08:23:35Z

update PR.
(1) change sof_bes_setup to sof_nocodec_bes_setup
(2) use hda machine driver if both hda codec and hdmi codec are found
(3) check the error flow and discuss with keyon.
(4) test on WHL and UP with I2S and nocodec

Thanks!

plbossart · 2019-01-16T20:23:05Z

@RanderWang @plbossart a question unrelated to this PR but related to the choice of machine drivers in general.

For boards like WHL RVP without any codecs, can we just test HDMI playback with SOF and if so which machine driver should be chosen in this case?

The skl_generic_hda machine driver should just work, it supports either HDMI or HDMI+HDaudio codec combinations.

ranj063 · 2019-01-16T20:28:54Z

@RanderWang @plbossart a question unrelated to this PR but related to the choice of machine drivers in general.
For boards like WHL RVP without any codecs, can we just test HDMI playback with SOF and if so which machine driver should be chosen in this case?

The skl_generic_hda machine driver should just work, it supports either HDMI or HDMI+HDaudio codec combinations.

Oh thats cool. The reason I asked this was to see if we could test HDMI playback on the CML boards that dont have any codecs. Let me give this a try.

plbossart

Thanks @RanderWang and @keyonjie, this is starting to take shape, I have only a couple of comments on the selection of the HDaudio machine driver. As @ranj063 was suggesting in a comment, we need to deal with headless devices where HDMI is the only form of user interaction

plbossart · 2019-01-16T20:43:13Z

sound/soc/sof/intel/hda.c

This is a good start but we can make it more general to handle multiple situations:
0. codec_num = 0 -> use nocodec if enabled in the build

codec_num = 1 -> use nocodec if enabled in the build (for validation)

codec_num = 1 -> use HDMI (for user interaction e.g. on a headless device like Up2)

codec_num = 2 -> use HDMI + HDAudio

Also for HDMI you need to verify that bit2 is set, it's not just the number of codecs that matters.
Also you would need to set the HDAudio machine driver only if there is no ACPI ID (or machine already set).

Makes sense?

yes , 1 and 2 is what I want but I was failed to get.

And I get the number of codecs because I am not sure HDMI is always identified by bit2. I searched the HDA spec, still didn't find it. But on our platforms, I find it is always at bit2.

I will check machine driver is none or not here before using HDA machine driver.

RanderWang · 2019-01-17T06:03:29Z

update my PR according to new criterion.
I tested on WHL, UP with I2S, HDA with HDMI only, and nocodec mode.
Thanks for review!

ranj063 · 2019-01-17T06:23:36Z

sound/soc/sof/sof-pci-dev.c

@RanderWang no need for braces here?

yes, I will refine it. Thanks!

plbossart

Almost there. I'd like a minor tweak since the machine driver can only support one external HDaudio codec, and a fix on a macro prefix. Let's merge this week.

plbossart · 2019-01-17T16:40:56Z

sound/soc/sof/intel/hda.c

Actually for the first case we need to double check HDMI is present (codec_num>1 is not enough in theory, there could be two HDaudio codecs which isn't supported). Something like this would work:

if (HDA_IDISP_CODEC(bus->codec_mask)) { if (codec_num == 2 || !IS_ENABLED(CONFIG_SND_SOC_SOF_NOCODEC)) { hda_mach = snd_soc_acpi_intel_hda_machines; } }

yes, this I am uncertain about. Thanks!

plbossart · 2019-01-17T16:43:49Z

sound/soc/sof/intel/hda.c

no need for extra indirection, machine = pdata->machine would work (and be consistent with code above)

yes, I will refine it. Thanks!

plbossart · 2019-01-17T16:44:13Z

sound/soc/sof/intel/hda.h

HDA_IDISP_CODEC
let's make the macros consistent in terms of prefix

yes, I will refine it. Thanks!

plbossart · 2019-01-17T16:45:01Z

sound/soc/sof/intel/hda.c

there is one HDMI codec and one external HDAudio codec.

yes, I will refine it

plbossart · 2019-01-17T21:25:33Z

Sorry fellows, we have to rethink the whole thing due to new technical information (which is less than a week old).

Issue #560 exposes a new requirement that the HDaudio initialization be done in a work queue to avoid deadlocks with request_module being called in a probe function.

In other words, with the recommended approach, we will not know when snd_sof_probe() returns if there are HDaudio codecs detected.
An alternate solution might be to execute the bulk of sof_probe in a work queue, so that there is no HDaudio specific work required and your solution would work without changes.

In all cases what this means is that the probe issues cannot be directly reported to the PCI probe layers, making our PM stuff even more iffy.

RanderWang · 2019-01-18T09:20:44Z

@plbossart @keyonjie All my change in sof core is done after snd_sof_probe which is now move to sof_probe_continue. So I think the rework for PR is not difficult.

plbossart · 2019-01-18T17:38:52Z

@plbossart @keyonjie All my change in sof core is done after snd_sof_probe which is now move to sof_probe_continue. So I think the rework for PR is not difficult.

Indeed, I ended-up trying the "alternate solution" and it's compatible with your approach. Only need to get the PM parts right now.

plbossart · 2019-01-18T17:40:57Z

@plbossart @keyonjie All my change in sof core is done after snd_sof_probe which is now move to sof_probe_continue. So I think the rework for PR is not difficult.

Indeed, I ended-up trying the "alternate solution" and it's compatible with your approach. Only need to get the PM parts right now.

So what this means is that you can provide updates and I'll merge them, thanks. don't put this on the back burner waiting for the workqueue to be handled, it can be done later.

ranj063 · 2019-01-19T22:06:12Z

@RanderWang @plbossart a question unrelated to this PR but related to the choice of machine drivers in general.
For boards like WHL RVP without any codecs, can we just test HDMI playback with SOF and if so which machine driver should be chosen in this case?

The skl_generic_hda machine driver should just work, it supports either HDMI or HDMI+HDaudio codec combinations.

@plbossart i thought about a bit more and for me to get this to work, I need a new topology with just the HDMI pipelines. Is there a way we could combine the nocodec machine driver to add the iDisp DAI's. That way we could have one topology to test both no i2s codecs and hdmi playback.

RanderWang · 2019-01-21T07:21:09Z

@plbossart i thought about a bit more and for me to get this to work, I need a new topology with just the HDMI pipelines. Is there a way we could combine the nocodec machine driver to add the iDisp DAI's. That way we could have one topology to test both no i2s codecs and hdmi playback.

You could test hdmi with hda machine and i2s with nocodec machine.
In my opinion , there is a codec in HDMI and IDISP should not be included by nocodec machine.

It is ugly in pci probing function to check hda for machine driver. Now select hda machine driver in hda probing function and use nocodec machine driver if none of I2S or hda is selected after dsp probing Check following conditions to select machine driver 1. codec_num = 2 -> use hda with HDMI + HDAudio 2. codec_num = 1 -> use hda with HDMI if nocdec is disabled 3. codec_num = 1 -> use nocodec if enabled in the build (for validation) 4. codec_num = 0 -> use nocodec if enabled in the build step 2 is for on a headless device like Up2 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>

The change for machine driver would make a error that sof and nocodec module are dependent on each other. Signed-off-by: Rander Wang <rander.wang@linux.intel.com>

RanderWang · 2019-01-21T09:26:19Z

Update my PR.
Test on WHL & UP2

Thanks!

plbossart · 2019-01-22T16:51:10Z

@plbossart i thought about a bit more and for me to get this to work, I need a new topology with just the HDMI pipelines. Is there a way we could combine the nocodec machine driver to add the iDisp DAI's. That way we could have one topology to test both no i2s codecs and hdmi playback.

@ranj063 indeed, when we use HDMI only we should use a topology that doesn't have the HDAudio parts, but that's a small change in the topology filename. We can do this in a follow-up PR.
We can't really use HDMI in nocodec mode, we'd need a machine driver that deals with the jack and PCM creation, it's really ugly.

plbossart · 2019-01-22T16:58:43Z

@plbossart i thought about a bit more and for me to get this to work, I need a new topology with just the HDMI pipelines. Is there a way we could combine the nocodec machine driver to add the iDisp DAI's. That way we could have one topology to test both no i2s codecs and hdmi playback.

@ranj063 indeed, when we use HDMI only we should use a topology that doesn't have the HDAudio parts, but that's a small change in the topology filename. We can do this in a follow-up PR.
We can't really use HDMI in nocodec mode, we'd need a machine driver that deals with the jack and PCM creation, it's really ugly.

Just to make it a bit more complex, we can also have DMICs attached on up2, and DMICs attached on a platform with HDAudio codecs (as on the Acer Swift3 laptop), so we'll have to deal with all of these combinations.

HDAudio codec + HDMI
HDAudio codec + HDMI + DMICs
HDMI + DMICs
HDMI

That's why I suggested a long time ago a notion of "incremental" topology, where we'd have multiple files instead of multiple topologies.

plbossart · 2019-01-22T17:00:12Z

merging for now, we'll deal with the headless devices in another PR.

keyonjie · 2019-01-23T07:14:00Z

@RanderWang travis captured an building warning, can you send another PR to fix it please?

https://travis-ci.org/thesofproject/linux/jobs/482310276#L1043

RanderWang · 2019-01-23T07:52:36Z

@RanderWang travis captured an building warning, can you send another PR to fix it please?

https://travis-ci.org/thesofproject/linux/jobs/482310276#L1043

done

wenqingfu · 2019-01-25T19:20:26Z

should you do the same on the acpi path (sof-acpi-dev.c), too? @RanderWang

plbossart · 2019-01-25T20:39:54Z

should you do the same on the acpi path (sof-acpi-dev.c), too? @RanderWang <https://github.com/RanderWang>

No, this is not needed. For the ACPI path, we know already what the codecs are (as defined by their ACPI HID exposed in DSDT tables). There is no discoverability, ACPI tells you everything you need to know already.

…

…ntries Jiri Olsa reported a fault when running: # cat /proc/kallsyms | grep ksys_read ffffffff8136d580 T ksys_read # objdump -d --start-address=0xffffffff8136d580 --stop-address=0xffffffff8136d590 /proc/kcore /proc/kcore: file format elf64-x86-64 Segmentation fault general protection fault, probably for non-canonical address 0xf887ffcbff000: 0000 [thesofproject#1] SMP PTI CPU: 12 PID: 1079 Comm: objdump Not tainted 5.14.0-rc5qemu+ thesofproject#508 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:kern_addr_valid Call Trace: read_kcore ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? trace_hardirqs_on ? rcu_read_lock_sched_held ? lock_acquire ? lock_acquire ? rcu_read_lock_sched_held ? lock_acquire ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? lock_release ? _raw_spin_unlock ? __handle_mm_fault ? rcu_read_lock_sched_held ? lock_acquire ? rcu_read_lock_sched_held ? lock_release proc_reg_read ? vfs_read vfs_read ksys_read do_syscall_64 entry_SYSCALL_64_after_hwframe The fault happens because kern_addr_valid() dereferences existent but not present PMD in the high kernel mappings. Such PMDs are created when free_kernel_image_pages() frees regions larger than 2Mb. In this case, a part of the freed memory is mapped with PMDs and the set_memory_np_noalias() -> ... -> __change_page_attr() sequence will mark the PMD as not present rather than wipe it completely. Have kern_addr_valid() check whether higher level page table entries are present before trying to dereference them to fix this issue and to avoid similar issues in the future. Stable backporting note: ------------------------ Note that the stable marking is for all active stable branches because there could be cases where pagetable entries exist but are not valid - see 9a14aef ("x86: cpa, fix lookup_address"), for example. So make sure to be on the safe side here and use pXY_present() accessors rather than pXY_none() which could #GP when accessing pages in the direct map. Also see: c40a56a ("x86/mm/init: Remove freed kernel image areas from alias mapping") for more info. Reported-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Dave Hansen <dave.hansen@intel.com> Tested-by: Jiri Olsa <jolsa@redhat.com> Cc: <stable@vger.kernel.org> # 4.4+ Link: https://lkml.kernel.org/r/20210819132717.19358-1-rppt@kernel.org

RanderWang requested review from keyonjie and plbossart January 7, 2019 07:01

RanderWang force-pushed the hda_detection branch from 0a6d4a8 to 28807ac Compare January 7, 2019 07:25

plbossart requested changes Jan 7, 2019

View reviewed changes

RanderWang force-pushed the hda_detection branch 2 times, most recently from 9a1f482 to 17634ab Compare January 9, 2019 06:57

plbossart reviewed Jan 9, 2019

View reviewed changes

RanderWang force-pushed the hda_detection branch 3 times, most recently from 286cad6 to 51be44c Compare January 10, 2019 08:57

RanderWang force-pushed the hda_detection branch 3 times, most recently from 81869d9 to 698b310 Compare January 14, 2019 09:44

plbossart reviewed Jan 14, 2019

View reviewed changes

RanderWang force-pushed the hda_detection branch 2 times, most recently from 9c75e9a to 41aad7f Compare January 16, 2019 06:30

plbossart reviewed Jan 16, 2019

View reviewed changes

RanderWang force-pushed the hda_detection branch 3 times, most recently from 9d54217 to 6d76576 Compare January 17, 2019 05:57

ranj063 reviewed Jan 17, 2019

View reviewed changes

plbossart reviewed Jan 17, 2019

View reviewed changes

RanderWang force-pushed the hda_detection branch from 6d76576 to d90e25e Compare January 21, 2019 08:28

RanderWang force-pushed the hda_detection branch from d90e25e to 556c652 Compare January 21, 2019 08:40

ASoC: SOF: move sof_bes_setup to nocodec file

556c652

The change for machine driver would make a error that sof and nocodec module are dependent on each other. Signed-off-by: Rander Wang <rander.wang@linux.intel.com>

plbossart merged commit d3c50a2 into thesofproject:topic/sof-dev Jan 22, 2019

ASOC: SOF: choose hda machine driver if hda codes detected #508

ASOC: SOF: choose hda machine driver if hda codes detected #508

Uh oh!

Conversation

RanderWang commented Jan 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RanderWang commented Jan 7, 2019

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

RanderWang commented Jan 8, 2019

Uh oh!

plbossart commented Jan 8, 2019

Uh oh!

RanderWang commented Jan 8, 2019

Uh oh!

RanderWang commented Jan 9, 2019

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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

plbossart commented Jan 10, 2019 via email

Uh oh!

RanderWang commented Jan 10, 2019

Uh oh!

plbossart commented Jan 10, 2019

Uh oh!

keyonjie commented Jan 11, 2019

Uh oh!

plbossart commented Jan 11, 2019 via email

Uh oh!

keyonjie commented Jan 14, 2019

Uh oh!

RanderWang commented Jan 14, 2019

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

keyonjie Jan 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RanderWang commented Jan 7, 2019 •

edited

Loading

keyonjie Jan 15, 2019 •

edited

Loading