| Message ID | 20190321161055.26582-17-pierre-louis.bossart@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ASoC: Sound Open Firmware (SOF) - Intel support | expand |
On Thu, Mar 21, 2019 at 11:10:51AM -0500, Pierre-Louis Bossart wrote: > From: Liam Girdwood <liam.r.girdwood@linux.intel.com> > > Add support for PCI based DSP devices. > +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) Can we use Merrifield / mrfld instead of EDISON in entire series?
On Thu, Mar 28, 2019 at 07:48:19PM +0200, Andy Shevchenko wrote: > On Thu, Mar 21, 2019 at 11:10:51AM -0500, Pierre-Louis Bossart wrote: > > From: Liam Girdwood <liam.r.girdwood@linux.intel.com> > > > > Add support for PCI based DSP devices. > > > +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) > > Can we use Merrifield / mrfld instead of EDISON in entire series? And one more question, is there any howto to run a nocodec variant of SOF on Intel Merrifield platform?
Heya Andy, >>> +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) >> >> Can we use Merrifield / mrfld instead of EDISON in entire series? we could, but I don't know of any other platform than Edison to run the code. I know it's less accurate from an architecture perspective but felt Merrifield was confusing for non-Intel folks. > And one more question, is there any howto to run a nocodec variant of SOF on > Intel Merrifield platform? I haven't had time to look into this with the slew of comments on v3/v4 and travel. If you have a working Edison setup with 5.0+, then this should work as is. the main issue is going to describe the SSP2 pins with ACPI ASL stuff to make sure they are in 3.3V and the right pinmux, that's the part that I keep kicking down the road. When I used Edison with the official built there was a 'simple' script for the pin-mux, if you have the moral equivalent in ASL I am all ears -Pierre
On Thu, Mar 28, 2019 at 02:21:47PM -0400, Pierre-Louis Bossart wrote: > > > > +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) > > > > > > Can we use Merrifield / mrfld instead of EDISON in entire series? > > we could, but I don't know of any other platform than Edison to run the > code. I know it's less accurate from an architecture perspective but felt > Merrifield was confusing for non-Intel folks. We use Merrifield across the entire kernel. It would be confusing other way around. So, please, change it to be consistent with the rest of the kernel. > > And one more question, is there any howto to run a nocodec variant of SOF on > > Intel Merrifield platform? > > I haven't had time to look into this with the slew of comments on v3/v4 and > travel. If you have a working Edison setup with 5.0+, then this should work > as is. Where to get SOF binary, and more interesting where to get sources and howto compile them into binary? > the main issue is going to describe the SSP2 pins with ACPI ASL stuff > to make sure they are in 3.3V and the right pinmux, that's the part that I > keep kicking down the road. When I used Edison with the official built there > was a 'simple' script for the pin-mux, if you have the moral equivalent in > ASL I am all ears I don't know what should be done and where, the pins themselves are in correct mode set by firmware (if no-one touches them as GPIOs): pin 75 (GP40_I2S_2_CLK) mode 1 0x00003221 pin 76 (GP41_I2S_2_FS) mode 1 0x00003221 pin 77 (GP42_I2S_2_RXD) mode 1 0x00003221 pin 78 (GP43_I2S_2_TXD) mode 1 0x00003221 If you talking about Edison/Arduino board and its discrete pin control, we have a mechanism to set it from ASL.
On 3/28/19 6:08 PM, Andy Shevchenko wrote: > On Thu, Mar 28, 2019 at 02:21:47PM -0400, Pierre-Louis Bossart wrote: >>>>> +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) >>>> >>>> Can we use Merrifield / mrfld instead of EDISON in entire series? >> >> we could, but I don't know of any other platform than Edison to run the >> code. I know it's less accurate from an architecture perspective but felt >> Merrifield was confusing for non-Intel folks. > > We use Merrifield across the entire kernel. It would be confusing other way around. > So, please, change it to be consistent with the rest of the kernel. Since this is the only comment so far, I'll add a follow-up patch. > >>> And one more question, is there any howto to run a nocodec variant of SOF on >>> Intel Merrifield platform? >> >> I haven't had time to look into this with the slew of comments on v3/v4 and >> travel. If you have a working Edison setup with 5.0+, then this should work >> as is. > > Where to get SOF binary, and more interesting where to get sources and howto > compile them into binary? > >> the main issue is going to describe the SSP2 pins with ACPI ASL stuff >> to make sure they are in 3.3V and the right pinmux, that's the part that I >> keep kicking down the road. When I used Edison with the official built there >> was a 'simple' script for the pin-mux, if you have the moral equivalent in >> ASL I am all ears > > I don't know what should be done and where, the pins themselves are in correct > mode set by firmware (if no-one touches them as GPIOs): > > pin 75 (GP40_I2S_2_CLK) mode 1 0x00003221 > pin 76 (GP41_I2S_2_FS) mode 1 0x00003221 > pin 77 (GP42_I2S_2_RXD) mode 1 0x00003221 > pin 78 (GP43_I2S_2_TXD) mode 1 0x00003221 > > If you talking about Edison/Arduino board and its discrete pin control, we have > a mechanism to set it from ASL. yep, that's the board I have.
On Fri, 2019-03-29 at 00:08 +0200, Andy Shevchenko wrote: > On Thu, Mar 28, 2019 at 02:21:47PM -0400, Pierre-Louis Bossart wrote: > > > > > +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) > > > > > > > > Can we use Merrifield / mrfld instead of EDISON in entire > > > > series? > > > > we could, but I don't know of any other platform than Edison to run > > the > > code. I know it's less accurate from an architecture perspective > > but felt > > Merrifield was confusing for non-Intel folks. > > We use Merrifield across the entire kernel. It would be confusing > other way around. > So, please, change it to be consistent with the rest of the kernel. > > > > And one more question, is there any howto to run a nocodec > > > variant of SOF on > > > Intel Merrifield platform? > > > > I haven't had time to look into this with the slew of comments on > > v3/v4 and > > travel. If you have a working Edison setup with 5.0+, then this > > should work > > as is. > > Where to get SOF binary, and more interesting where to get sources > and howto > compile them into binary? Hi Andy, You can find the SOF sources and instructions to build the FW here: https://github.com/thesofproject/sof Thanks, Ranjani > > > the main issue is going to describe the SSP2 pins with ACPI ASL > > stuff > > to make sure they are in 3.3V and the right pinmux, that's the part > > that I > > keep kicking down the road. When I used Edison with the official > > built there > > was a 'simple' script for the pin-mux, if you have the moral > > equivalent in > > ASL I am all ears > > I don't know what should be done and where, the pins themselves are > in correct > mode set by firmware (if no-one touches them as GPIOs): > > pin 75 (GP40_I2S_2_CLK) mode 1 0x00003221 > pin 76 (GP41_I2S_2_FS) mode 1 0x00003221 > pin 77 (GP42_I2S_2_RXD) mode 1 0x00003221 > pin 78 (GP43_I2S_2_TXD) mode 1 0x00003221 > > If you talking about Edison/Arduino board and its discrete pin > control, we have > a mechanism to set it from ASL. >
On Thu, Mar 28, 2019 at 02:21:47PM -0400, Pierre-Louis Bossart wrote: > > > > +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) > > > Can we use Merrifield / mrfld instead of EDISON in entire series? > we could, but I don't know of any other platform than Edison to run the > code. I know it's less accurate from an architecture perspective but felt > Merrifield was confusing for non-Intel folks. I'm not sure any of this is particularly clear for non-Intel people...
On 3/29/19 8:30 PM, Pierre-Louis Bossart wrote: > On 3/28/19 6:08 PM, Andy Shevchenko wrote: >> On Thu, Mar 28, 2019 at 02:21:47PM -0400, Pierre-Louis Bossart wrote: >>>>>> +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) >>>>> >>>>> Can we use Merrifield / mrfld instead of EDISON in entire series? >>> >>> we could, but I don't know of any other platform than Edison to run the >>> code. I know it's less accurate from an architecture perspective but >>> felt >>> Merrifield was confusing for non-Intel folks. >> >> We use Merrifield across the entire kernel. It would be confusing >> other way around. >> So, please, change it to be consistent with the rest of the kernel. > > Since this is the only comment so far, I'll add a follow-up patch. Discard this reply, I'll address this in an update to address Takashi's comments as well. Actually I need feedback from reviewers/maintainers: I could either provide an update addressing just comments from Andy and Takashi, or provide a larger update that would include known fixes and simplifications from SOF contributors on github, e.g. on the IPC. We have about 15-20 delta patches that were accepted on github, not sure what the preference is, just addressing comments so far or getting the latest and greatest patches squashed?
On Mon, 01 Apr 2019 19:26:13 +0200, Pierre-Louis Bossart wrote: > > On 3/29/19 8:30 PM, Pierre-Louis Bossart wrote: > > On 3/28/19 6:08 PM, Andy Shevchenko wrote: > >> On Thu, Mar 28, 2019 at 02:21:47PM -0400, Pierre-Louis Bossart wrote: > >>>>>> +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) > >>>>> > >>>>> Can we use Merrifield / mrfld instead of EDISON in entire series? > >>> > >>> we could, but I don't know of any other platform than Edison to run the > >>> code. I know it's less accurate from an architecture perspective > >>> but felt > >>> Merrifield was confusing for non-Intel folks. > >> > >> We use Merrifield across the entire kernel. It would be confusing > >> other way around. > >> So, please, change it to be consistent with the rest of the kernel. > > > > Since this is the only comment so far, I'll add a follow-up patch. > > Discard this reply, I'll address this in an update to address > Takashi's comments as well. > > > Actually I need feedback from reviewers/maintainers: I could either > provide an update addressing just comments from Andy and Takashi, or > provide a larger update that would include known fixes and > simplifications from SOF contributors on github, e.g. on the IPC. We > have about 15-20 delta patches that were accepted on github, not sure > what the preference is, just addressing comments so far or getting the > latest and greatest patches squashed? IMO, one or two more whole patchset refresh would be still worth. Then we can merge the base, and go for refinement with each small change, hopefully in this merge cycle. For the resubmission, please give me a bit more time. I had no time for further review in the last week due to completely other businesses (the office room movement, etc)... thanks, Takashi
On 4/1/19 3:05 PM, Takashi Iwai wrote: > On Mon, 01 Apr 2019 19:26:13 +0200, > Pierre-Louis Bossart wrote: >> >> On 3/29/19 8:30 PM, Pierre-Louis Bossart wrote: >>> On 3/28/19 6:08 PM, Andy Shevchenko wrote: >>>> On Thu, Mar 28, 2019 at 02:21:47PM -0400, Pierre-Louis Bossart wrote: >>>>>>>> +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) >>>>>>> >>>>>>> Can we use Merrifield / mrfld instead of EDISON in entire series? >>>>> >>>>> we could, but I don't know of any other platform than Edison to run the >>>>> code. I know it's less accurate from an architecture perspective >>>>> but felt >>>>> Merrifield was confusing for non-Intel folks. >>>> >>>> We use Merrifield across the entire kernel. It would be confusing >>>> other way around. >>>> So, please, change it to be consistent with the rest of the kernel. >>> >>> Since this is the only comment so far, I'll add a follow-up patch. >> >> Discard this reply, I'll address this in an update to address >> Takashi's comments as well. >> >> >> Actually I need feedback from reviewers/maintainers: I could either >> provide an update addressing just comments from Andy and Takashi, or >> provide a larger update that would include known fixes and >> simplifications from SOF contributors on github, e.g. on the IPC. We >> have about 15-20 delta patches that were accepted on github, not sure >> what the preference is, just addressing comments so far or getting the >> latest and greatest patches squashed? > > IMO, one or two more whole patchset refresh would be still worth. > Then we can merge the base, and go for refinement with each small > change, hopefully in this merge cycle. > > For the resubmission, please give me a bit more time. I had no time > for further review in the last week due to completely other > businesses (the office room movement, etc)... Sure, I am understand how time consuming this can be and how 'reviewer fatigue' can occur. We can add a couple of additional changes, e.g. for the IPC and some resource management while you (and others) go over the current patchset and tentatively resubmit next week, would that work?
On Mon, Apr 01, 2019 at 05:59:16PM -0400, Pierre-Louis Bossart wrote: > On 4/1/19 3:05 PM, Takashi Iwai wrote: > > > Actually I need feedback from reviewers/maintainers: I could either > > > provide an update addressing just comments from Andy and Takashi, or > > > provide a larger update that would include known fixes and > > > simplifications from SOF contributors on github, e.g. on the IPC. We > > > have about 15-20 delta patches that were accepted on github, not sure > > > what the preference is, just addressing comments so far or getting the > > > latest and greatest patches squashed? > > IMO, one or two more whole patchset refresh would be still worth. > > Then we can merge the base, and go for refinement with each small > > change, hopefully in this merge cycle. Especially with the fixes just always add them, there's no sense in not fixing bugs. > > For the resubmission, please give me a bit more time. I had no time > > for further review in the last week due to completely other > > businesses (the office room movement, etc)... > Sure, I am understand how time consuming this can be and how 'reviewer > fatigue' can occur. We can add a couple of additional changes, e.g. for the > IPC and some resource management while you (and others) go over the current > patchset and tentatively resubmit next week, would that work? That seems fine to me.
On Mon, 01 Apr 2019 21:05:23 +0200, Takashi Iwai wrote: > > On Mon, 01 Apr 2019 19:26:13 +0200, > Pierre-Louis Bossart wrote: > > > > On 3/29/19 8:30 PM, Pierre-Louis Bossart wrote: > > > On 3/28/19 6:08 PM, Andy Shevchenko wrote: > > >> On Thu, Mar 28, 2019 at 02:21:47PM -0400, Pierre-Louis Bossart wrote: > > >>>>>> +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) > > >>>>> > > >>>>> Can we use Merrifield / mrfld instead of EDISON in entire series? > > >>> > > >>> we could, but I don't know of any other platform than Edison to run the > > >>> code. I know it's less accurate from an architecture perspective > > >>> but felt > > >>> Merrifield was confusing for non-Intel folks. > > >> > > >> We use Merrifield across the entire kernel. It would be confusing > > >> other way around. > > >> So, please, change it to be consistent with the rest of the kernel. > > > > > > Since this is the only comment so far, I'll add a follow-up patch. > > > > Discard this reply, I'll address this in an update to address > > Takashi's comments as well. > > > > > > Actually I need feedback from reviewers/maintainers: I could either > > provide an update addressing just comments from Andy and Takashi, or > > provide a larger update that would include known fixes and > > simplifications from SOF contributors on github, e.g. on the IPC. We > > have about 15-20 delta patches that were accepted on github, not sure > > what the preference is, just addressing comments so far or getting the > > latest and greatest patches squashed? > > IMO, one or two more whole patchset refresh would be still worth. > Then we can merge the base, and go for refinement with each small > change, hopefully in this merge cycle. > > For the resubmission, please give me a bit more time. I had no time > for further review in the last week due to completely other > businesses (the office room movement, etc)... OK, the review of the series is done now. Looking forward to seeing a new series. thanks, Takashi
>> IMO, one or two more whole patchset refresh would be still worth. >> Then we can merge the base, and go for refinement with each small >> change, hopefully in this merge cycle. >> >> For the resubmission, please give me a bit more time. I had no time >> for further review in the last week due to completely other >> businesses (the office room movement, etc)... > > OK, the review of the series is done now. > Looking forward to seeing a new series. Thanks Takashi for the reviews!
diff --git a/sound/soc/sof/sof-pci-dev.c b/sound/soc/sof/sof-pci-dev.c new file mode 100644 index 000000000000..556c718df1a3 --- /dev/null +++ b/sound/soc/sof/sof-pci-dev.c @@ -0,0 +1,373 @@ +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) +// +// This file is provided under a dual BSD/GPLv2 license. When using or +// redistributing this file, you may do so under either license. +// +// Copyright(c) 2018 Intel Corporation. All rights reserved. +// +// Author: Liam Girdwood <liam.r.girdwood@linux.intel.com> +// + +#include <linux/firmware.h> +#include <linux/module.h> +#include <linux/pci.h> +#include <linux/pm_runtime.h> +#include <sound/soc-acpi.h> +#include <sound/soc-acpi-intel-match.h> +#include <sound/sof.h> +#include "ops.h" + +/* platform specific devices */ +#include "intel/shim.h" +#include "intel/hda.h" + +static char *fw_path; +module_param(fw_path, charp, 0444); +MODULE_PARM_DESC(fw_path, "alternate path for SOF firmware."); + +static char *tplg_path; +module_param(tplg_path, charp, 0444); +MODULE_PARM_DESC(tplg_path, "alternate path for SOF topology."); + +#if IS_ENABLED(CONFIG_SND_SOC_SOF_APOLLOLAKE) +static const struct sof_dev_desc bxt_desc = { + .machines = snd_soc_acpi_intel_bxt_machines, + .resindex_lpe_base = 0, + .resindex_pcicfg_base = -1, + .resindex_imr_base = -1, + .irqindex_host_ipc = -1, + .resindex_dma_base = -1, + .chip_info = &apl_chip_info, + .default_fw_path = "intel/sof", + .default_tplg_path = "intel/sof-tplg", + .nocodec_fw_filename = "sof-apl.ri", + .nocodec_tplg_filename = "sof-apl-nocodec.tplg", + .ops = &sof_apl_ops, + .arch_ops = &sof_xtensa_arch_ops +}; +#endif + +#if IS_ENABLED(CONFIG_SND_SOC_SOF_GEMINILAKE) +static const struct sof_dev_desc glk_desc = { + .machines = snd_soc_acpi_intel_glk_machines, + .resindex_lpe_base = 0, + .resindex_pcicfg_base = -1, + .resindex_imr_base = -1, + .irqindex_host_ipc = -1, + .resindex_dma_base = -1, + .chip_info = &apl_chip_info, + .default_fw_path = "intel/sof", + .default_tplg_path = "intel/sof-tplg", + .nocodec_fw_filename = "sof-glk.ri", + .nocodec_tplg_filename = "sof-glk-nocodec.tplg", + .ops = &sof_apl_ops, + .arch_ops = &sof_xtensa_arch_ops +}; +#endif + +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) +static struct snd_soc_acpi_mach sof_tng_machines[] = { + { + .id = "INT343A", + .drv_name = "edison", + .sof_fw_filename = "sof-byt.ri", + .sof_tplg_filename = "sof-byt.tplg", + }, + {} +}; + +static const struct sof_dev_desc tng_desc = { + .machines = sof_tng_machines, + .resindex_lpe_base = 3, /* IRAM, but subtract IRAM offset */ + .resindex_pcicfg_base = -1, + .resindex_imr_base = 0, + .irqindex_host_ipc = -1, + .resindex_dma_base = -1, + .chip_info = &tng_chip_info, + .default_fw_path = "intel/sof", + .default_tplg_path = "intel/sof-tplg", + .nocodec_fw_filename = "sof-byt.ri", + .nocodec_tplg_filename = "sof-byt.tplg", + .ops = &sof_tng_ops, + .arch_ops = &sof_xtensa_arch_ops +}; +#endif + +#if IS_ENABLED(CONFIG_SND_SOC_SOF_CANNONLAKE) +static const struct sof_dev_desc cnl_desc = { + .machines = snd_soc_acpi_intel_cnl_machines, + .resindex_lpe_base = 0, + .resindex_pcicfg_base = -1, + .resindex_imr_base = -1, + .irqindex_host_ipc = -1, + .resindex_dma_base = -1, + .chip_info = &cnl_chip_info, + .default_fw_path = "intel/sof", + .default_tplg_path = "intel/sof-tplg", + .nocodec_fw_filename = "sof-cnl.ri", + .nocodec_tplg_filename = "sof-cnl-nocodec.tplg", + .ops = &sof_cnl_ops, + .arch_ops = &sof_xtensa_arch_ops +}; +#endif + +#if IS_ENABLED(CONFIG_SND_SOC_SOF_COFFEELAKE) +static const struct sof_dev_desc cfl_desc = { + .machines = snd_soc_acpi_intel_cnl_machines, + .resindex_lpe_base = 0, + .resindex_pcicfg_base = -1, + .resindex_imr_base = -1, + .irqindex_host_ipc = -1, + .resindex_dma_base = -1, + .chip_info = &cnl_chip_info, + .default_fw_path = "intel/sof", + .default_tplg_path = "intel/sof-tplg", + .nocodec_fw_filename = "sof-cnl.ri", + .nocodec_tplg_filename = "sof-cnl-nocodec.tplg", + .ops = &sof_cnl_ops, + .arch_ops = &sof_xtensa_arch_ops +}; +#endif + +#if IS_ENABLED(CONFIG_SND_SOC_SOF_ICELAKE) +static const struct sof_dev_desc icl_desc = { + .machines = snd_soc_acpi_intel_icl_machines, + .resindex_lpe_base = 0, + .resindex_pcicfg_base = -1, + .resindex_imr_base = -1, + .irqindex_host_ipc = -1, + .resindex_dma_base = -1, + .chip_info = &cnl_chip_info, + .default_fw_path = "intel/sof", + .default_tplg_path = "intel/sof-tplg", + .nocodec_fw_filename = "sof-icl.ri", + .nocodec_tplg_filename = "sof-icl-nocodec.tplg", + .ops = &sof_cnl_ops, + .arch_ops = &sof_xtensa_arch_ops +}; +#endif + +#if IS_ENABLED(CONFIG_SND_SOC_SOF_SKYLAKE) +static const struct sof_dev_desc skl_desc = { + .machines = snd_soc_acpi_intel_skl_machines, + .resindex_lpe_base = 0, + .resindex_pcicfg_base = -1, + .resindex_imr_base = -1, + .irqindex_host_ipc = -1, + .resindex_dma_base = -1, + .chip_info = &skl_chip_info, + .default_fw_path = "intel/sof", + .default_tplg_path = "intel/sof-tplg", + .nocodec_fw_filename = "sof-skl.ri", + .nocodec_tplg_filename = "sof-skl-nocodec.tplg", + .ops = &sof_skl_ops, + .arch_ops = &sof_xtensa_arch_ops +}; +#endif + +#if IS_ENABLED(CONFIG_SND_SOC_SOF_KABYLAKE) +static const struct sof_dev_desc kbl_desc = { + .machines = snd_soc_acpi_intel_kbl_machines, + .resindex_lpe_base = 0, + .resindex_pcicfg_base = -1, + .resindex_imr_base = -1, + .irqindex_host_ipc = -1, + .resindex_dma_base = -1, + .chip_info = &skl_chip_info, + .default_fw_path = "intel/sof", + .default_tplg_path = "intel/sof-tplg", + .nocodec_fw_filename = "sof-kbl.ri", + .nocodec_tplg_filename = "sof-kbl-nocodec.tplg", + .ops = &sof_skl_ops, + .arch_ops = &sof_xtensa_arch_ops +}; +#endif + +static const struct dev_pm_ops sof_pci_pm = { + SET_SYSTEM_SLEEP_PM_OPS(snd_sof_suspend, snd_sof_resume) + SET_RUNTIME_PM_OPS(snd_sof_runtime_suspend, snd_sof_runtime_resume, + NULL) +}; + +static void sof_pci_probe_complete(struct device *dev) +{ + dev_dbg(dev, "Completing SOF PCI probe"); + + /* allow runtime_pm */ + pm_runtime_set_autosuspend_delay(dev, SND_SOF_SUSPEND_DELAY_MS); + pm_runtime_use_autosuspend(dev); + + /* + * runtime pm for pci device is "forbidden" by default. + * so call pm_runtime_allow() to enable it. + */ + pm_runtime_allow(dev); + + /* follow recommendation in pci-driver.c to decrement usage counter */ + pm_runtime_put_noidle(dev); +} + +static int sof_pci_probe(struct pci_dev *pci, + const struct pci_device_id *pci_id) +{ + struct device *dev = &pci->dev; + const struct sof_dev_desc *desc = + (const struct sof_dev_desc *)pci_id->driver_data; + struct snd_soc_acpi_mach *mach; + struct snd_sof_pdata *sof_pdata; + const struct snd_sof_dsp_ops *ops; + int ret = 0; + + dev_dbg(&pci->dev, "PCI DSP detected"); + + /* get ops for platform */ + ops = desc->ops; + if (!ops) { + dev_err(dev, "error: no matching PCI descriptor ops\n"); + return -ENODEV; + } + + sof_pdata = devm_kzalloc(dev, sizeof(*sof_pdata), GFP_KERNEL); + if (!sof_pdata) + return -ENOMEM; + + ret = pcim_enable_device(pci); + if (ret < 0) + return ret; + + ret = pci_request_regions(pci, "Audio DSP"); + if (ret < 0) + return ret; + +#if IS_ENABLED(CONFIG_SND_SOC_SOF_FORCE_NOCODEC_MODE) + /* force nocodec mode */ + dev_warn(dev, "Force to use nocodec mode\n"); + mach = devm_kzalloc(dev, sizeof(*mach), GFP_KERNEL); + if (!mach) { + ret = -ENOMEM; + goto release_regions; + } + ret = sof_nocodec_setup(dev, sof_pdata, mach, desc, ops); + if (ret < 0) + goto release_regions; + +#else + /* find machine */ + mach = snd_soc_acpi_find_machine(desc->machines); + if (!mach) { + dev_warn(dev, "warning: No matching ASoC machine driver found\n"); + } else { + mach->mach_params.platform = dev_name(dev); + sof_pdata->fw_filename = mach->sof_fw_filename; + sof_pdata->tplg_filename = mach->sof_tplg_filename; + } +#endif /* CONFIG_SND_SOC_SOF_FORCE_NOCODEC_MODE */ + + sof_pdata->name = pci_name(pci); + sof_pdata->machine = mach; + sof_pdata->desc = (struct sof_dev_desc *)pci_id->driver_data; + sof_pdata->dev = dev; + sof_pdata->platform = dev_name(dev); + + /* alternate fw and tplg filenames ? */ + if (fw_path) + sof_pdata->fw_filename_prefix = fw_path; + else + sof_pdata->fw_filename_prefix = + sof_pdata->desc->default_fw_path; + + if (tplg_path) + sof_pdata->tplg_filename_prefix = tplg_path; + else + sof_pdata->tplg_filename_prefix = + sof_pdata->desc->default_tplg_path; + +#if IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE) + /* set callback to enable runtime_pm */ + sof_pdata->sof_probe_complete = sof_pci_probe_complete; +#endif + /* call sof helper for DSP hardware probe */ + ret = snd_sof_device_probe(dev, sof_pdata); + if (ret) { + dev_err(dev, "error: failed to probe DSP hardware!\n"); + goto release_regions; + } + +#if !IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE) + sof_pci_probe_complete(dev); +#endif + + return ret; + +release_regions: + pci_release_regions(pci); + + return ret; +} + +static void sof_pci_remove(struct pci_dev *pci) +{ + /* call sof helper for DSP hardware remove */ + snd_sof_device_remove(&pci->dev); + + /* follow recommendation in pci-driver.c to increment usage counter */ + pm_runtime_get_noresume(&pci->dev); + + /* release pci regions and disable device */ + pci_release_regions(pci); +} + +/* PCI IDs */ +static const struct pci_device_id sof_pci_ids[] = { +#if IS_ENABLED(CONFIG_SND_SOC_SOF_EDISON) + { PCI_DEVICE(0x8086, 0x119a), + .driver_data = (unsigned long)&tng_desc}, +#endif +#if IS_ENABLED(CONFIG_SND_SOC_SOF_APOLLOLAKE) + /* BXT-P & Apollolake */ + { PCI_DEVICE(0x8086, 0x5a98), + .driver_data = (unsigned long)&bxt_desc}, + { PCI_DEVICE(0x8086, 0x1a98), + .driver_data = (unsigned long)&bxt_desc}, +#endif +#if IS_ENABLED(CONFIG_SND_SOC_SOF_GEMINILAKE) + { PCI_DEVICE(0x8086, 0x3198), + .driver_data = (unsigned long)&glk_desc}, +#endif +#if IS_ENABLED(CONFIG_SND_SOC_SOF_CANNONLAKE) + { PCI_DEVICE(0x8086, 0x9dc8), + .driver_data = (unsigned long)&cnl_desc}, +#endif +#if IS_ENABLED(CONFIG_SND_SOC_SOF_COFFEELAKE) + { PCI_DEVICE(0x8086, 0xa348), + .driver_data = (unsigned long)&cfl_desc}, +#endif +#if IS_ENABLED(CONFIG_SND_SOC_SOF_KABYLAKE) + { PCI_DEVICE(0x8086, 0x9d71), + .driver_data = (unsigned long)&kbl_desc}, +#endif +#if IS_ENABLED(CONFIG_SND_SOC_SOF_SKYLAKE) + { PCI_DEVICE(0x8086, 0x9d70), + .driver_data = (unsigned long)&skl_desc}, +#endif +#if IS_ENABLED(CONFIG_SND_SOC_SOF_ICELAKE) + { PCI_DEVICE(0x8086, 0x34C8), + .driver_data = (unsigned long)&icl_desc}, +#endif + { 0, } +}; +MODULE_DEVICE_TABLE(pci, sof_pci_ids); + +/* pci_driver definition */ +static struct pci_driver snd_sof_pci_driver = { + .name = "sof-audio-pci", + .id_table = sof_pci_ids, + .probe = sof_pci_probe, + .remove = sof_pci_remove, + .driver = { + .pm = &sof_pci_pm, + }, +}; +module_pci_driver(snd_sof_pci_driver); + +MODULE_LICENSE("Dual BSD/GPL");