-
Notifications
You must be signed in to change notification settings - Fork 140
ICL ICCMAX support #2548
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICL ICCMAX support #2548
Changes from all commits
084fa85
774953c
2070477
09637e3
a048f6a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| /* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) */ | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. NAK on the file name. This has got to be "intel_ext_manifest.h" or something clearly identifying Intel and not the generic SOF stuff
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @plbossart it is already in intel/ directory, can it really be confused for being SOF-generic? I find it a bit confusing in general: in most cases I prefer to eliminate redundancy in file names, so, sound/soc/sof/core.c is clear, that it's the SOF core, not ASoC or even ALSA core.c. But we also have sound/soc/sof/sof-audio.[ch], sof-priv.[ch], sof-{acpi,of,pci}-dev.c which seem both inconsistent and redundant, but ok, we already have them, and I personally don't see that as important enough to merit renames. OTOH ASoC has all their .c files named as sound/soc/soc-*.c which does look redundant to me, but at least it's consistent :-) In short, personally I find group/function.c preferable over group/group-function.c and it does seem to me the prevailing variant. But maybe this is a special case...
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't like duplication in general either but note the number of "intel" occurrences in Now you also have to pray that the Many editors also show only the basename in their menus etc.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like unique file name personally as I manage all the files in a project. But I already found multiple same file names in linux kernel directory. My understanding... if same file in |
||
| /* | ||
| * 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) 2020 Intel Corporation. All rights reserved. | ||
| */ | ||
|
|
||
| /* | ||
| * Intel extended manifest is a extra place to store Intel cavs specific | ||
| * metadata about firmware, for example LPRO/HPRO configuration is | ||
| * Intel cavs specific. This part of output binary is not signed. | ||
| */ | ||
|
|
||
| #ifndef __INTEL_CAVS_EXT_MANIFEST_H__ | ||
| #define __INTEL_CAVS_EXT_MANIFEST_H__ | ||
|
|
||
| #include <sound/sof/ext_manifest.h> | ||
|
|
||
| /* EXT_MAN_ELEM_PLATFORM_CONFIG_DATA elements identificators */ | ||
| enum sof_cavs_config_elem_type { | ||
| SOF_EXT_MAN_CAVS_CONFIG_EMPTY = 0, | ||
plbossart marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what is the point of an EMPTY token that will be skipped anyways?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @plbossart I think the explanation here was to check against 0-initialised data, as used in
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We need explicit EMPTY token to skip, I think, this is better than just comparing 0. |
||
| SOF_EXT_MAN_CAVS_CONFIG_CAVS_LPRO = 1, | ||
| SOF_EXT_MAN_CAVS_CONFIG_OUTBOX_SIZE = 2, | ||
| SOF_EXT_MAN_CAVS_CONFIG_INBOX_SIZE = 3, | ||
| }; | ||
|
|
||
| /* EXT_MAN_ELEM_PLATFORM_CONFIG_DATA elements */ | ||
| struct sof_ext_man_cavs_config_data { | ||
| struct sof_ext_man_elem_header hdr; | ||
|
|
||
| struct sof_config_elem elems[]; | ||
| } __packed; | ||
|
|
||
| #endif /* __INTEL_CAVS_EXT_MANIFEST_H__ */ | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,145 @@ | ||
| // SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) | ||
| // | ||
| // Copyright(c) 2020 Intel Corporation. All rights reserved. | ||
| // | ||
| // Author: Fred Oh <fred.oh@linux.intel.com> | ||
| // | ||
|
|
||
| /* | ||
| * Hardware interface for audio DSP on IceLake. | ||
| */ | ||
|
|
||
| #include <linux/kernel.h> | ||
| #include <linux/kconfig.h> | ||
| #include <linux/export.h> | ||
| #include <linux/bits.h> | ||
| #include "../ops.h" | ||
| #include "hda.h" | ||
| #include "hda-ipc.h" | ||
| #include "../sof-audio.h" | ||
fredoh9 marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| static const struct snd_sof_debugfs_map icl_dsp_debugfs[] = { | ||
| {"hda", HDA_DSP_HDA_BAR, 0, 0x4000, SOF_DEBUGFS_ACCESS_ALWAYS}, | ||
| {"pp", HDA_DSP_PP_BAR, 0, 0x1000, SOF_DEBUGFS_ACCESS_ALWAYS}, | ||
| {"dsp", HDA_DSP_BAR, 0, 0x10000, SOF_DEBUGFS_ACCESS_ALWAYS}, | ||
| }; | ||
|
|
||
| /* Icelake ops */ | ||
| const struct snd_sof_dsp_ops sof_icl_ops = { | ||
| /* probe and remove */ | ||
| .probe = hda_dsp_probe, | ||
| .remove = hda_dsp_remove, | ||
|
|
||
| /* Register IO */ | ||
| .write = sof_io_write, | ||
| .read = sof_io_read, | ||
| .write64 = sof_io_write64, | ||
| .read64 = sof_io_read64, | ||
|
|
||
| /* Block IO */ | ||
| .block_read = sof_block_read, | ||
| .block_write = sof_block_write, | ||
|
|
||
| /* doorbell */ | ||
| .irq_thread = cnl_ipc_irq_thread, | ||
|
|
||
| /* ipc */ | ||
| .send_msg = cnl_ipc_send_msg, | ||
| .fw_ready = sof_fw_ready, | ||
| .get_mailbox_offset = hda_dsp_ipc_get_mailbox_offset, | ||
| .get_window_offset = hda_dsp_ipc_get_window_offset, | ||
|
|
||
| .ipc_msg_data = hda_ipc_msg_data, | ||
| .ipc_pcm_params = hda_ipc_pcm_params, | ||
|
|
||
| /* machine driver */ | ||
| .machine_select = hda_machine_select, | ||
| .machine_register = sof_machine_register, | ||
| .machine_unregister = sof_machine_unregister, | ||
| .set_mach_params = hda_set_mach_params, | ||
|
|
||
| /* debug */ | ||
| .debug_map = icl_dsp_debugfs, | ||
| .debug_map_count = ARRAY_SIZE(icl_dsp_debugfs), | ||
| .dbg_dump = hda_dsp_dump, | ||
| .ipc_dump = cnl_ipc_dump, | ||
|
|
||
| /* stream callbacks */ | ||
| .pcm_open = hda_dsp_pcm_open, | ||
| .pcm_close = hda_dsp_pcm_close, | ||
| .pcm_hw_params = hda_dsp_pcm_hw_params, | ||
| .pcm_hw_free = hda_dsp_stream_hw_free, | ||
| .pcm_trigger = hda_dsp_pcm_trigger, | ||
| .pcm_pointer = hda_dsp_pcm_pointer, | ||
|
|
||
| #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA_PROBES) | ||
| /* probe callbacks */ | ||
| .probe_assign = hda_probe_compr_assign, | ||
| .probe_free = hda_probe_compr_free, | ||
| .probe_set_params = hda_probe_compr_set_params, | ||
| .probe_trigger = hda_probe_compr_trigger, | ||
| .probe_pointer = hda_probe_compr_pointer, | ||
| #endif | ||
|
|
||
| /* firmware loading */ | ||
| .load_firmware = snd_sof_load_firmware_raw, | ||
|
|
||
| /* pre/post fw run */ | ||
| .pre_fw_run = hda_dsp_pre_fw_run, | ||
| .post_fw_run = hda_dsp_post_fw_run_icl, | ||
|
|
||
| /* parse platform specific extended manifest */ | ||
| .parse_platform_ext_manifest = hda_dsp_ext_man_get_cavs_config_data, | ||
|
|
||
| /* dsp core power up/down */ | ||
| .core_power_up = hda_dsp_enable_core, | ||
| .core_power_down = hda_dsp_core_reset_power_down, | ||
|
|
||
| /* firmware run */ | ||
| .run = hda_dsp_cl_boot_firmware_iccmax, | ||
| .stall = hda_dsp_core_stall_icl, | ||
|
|
||
| /* trace callback */ | ||
| .trace_init = hda_dsp_trace_init, | ||
| .trace_release = hda_dsp_trace_release, | ||
| .trace_trigger = hda_dsp_trace_trigger, | ||
|
|
||
| /* DAI drivers */ | ||
| .drv = skl_dai, | ||
| .num_drv = SOF_SKL_NUM_DAIS, | ||
|
|
||
| /* PM */ | ||
| .suspend = hda_dsp_suspend, | ||
| .resume = hda_dsp_resume, | ||
| .runtime_suspend = hda_dsp_runtime_suspend, | ||
| .runtime_resume = hda_dsp_runtime_resume, | ||
| .runtime_idle = hda_dsp_runtime_idle, | ||
| .set_hw_params_upon_resume = hda_dsp_set_hw_params_upon_resume, | ||
| .set_power_state = hda_dsp_set_power_state, | ||
|
|
||
| /* ALSA HW info flags */ | ||
| .hw_info = SNDRV_PCM_INFO_MMAP | | ||
| SNDRV_PCM_INFO_MMAP_VALID | | ||
| SNDRV_PCM_INFO_INTERLEAVED | | ||
| SNDRV_PCM_INFO_PAUSE | | ||
| SNDRV_PCM_INFO_NO_PERIOD_WAKEUP, | ||
|
|
||
| .arch_ops = &sof_xtensa_arch_ops, | ||
| }; | ||
| EXPORT_SYMBOL_NS(sof_icl_ops, SND_SOC_SOF_INTEL_HDA_COMMON); | ||
|
|
||
| const struct sof_intel_dsp_desc icl_chip_info = { | ||
| /* Icelake */ | ||
| .cores_num = 4, | ||
| .init_core_mask = 1, | ||
| .host_managed_cores_mask = GENMASK(3, 0), | ||
| .ipc_req = CNL_DSP_REG_HIPCIDR, | ||
| .ipc_req_mask = CNL_DSP_REG_HIPCIDR_BUSY, | ||
| .ipc_ack = CNL_DSP_REG_HIPCIDA, | ||
| .ipc_ack_mask = CNL_DSP_REG_HIPCIDA_DONE, | ||
| .ipc_ctl = CNL_DSP_REG_HIPCCTL, | ||
| .rom_init_timeout = 300, | ||
| .ssp_count = ICL_SSP_COUNT, | ||
| .ssp_base_offset = CNL_SSP_BASE_OFFSET, | ||
| }; | ||
| EXPORT_SYMBOL_NS(icl_chip_info, SND_SOC_SOF_INTEL_HDA_COMMON); | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw, @ranj063 and @fredoh9 -- while ICCMAX is somewhat known as a concept, in this case this is a very specific and non-obvious quirk of our DSP bootflow. I won't complain now as the same text is already merged for TGL in upstream, but the commit message is not very helpful for people outside SOF project. But yeah, I'm ok to go with this The bit about "recommended hw programming sequence" is key and it's there...