An error occurred fetching the project authors.
- 19 Mar, 2019 1 commit
-
-
Charles Keepax authored
If a watchdog timeout is received from the DSP it is safe to assume the DSP is not functioning anymore and as such any active compressed streams should be put into an error state. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
Mark Brown <broonie@kernel.org>
-
- 22 Feb, 2019 1 commit
-
-
Stuart Henderson authored
Currently, only a single compressed stream is supported per firmware. Add support for multiple compressed streams on a single firmware, this allows additional features like completely independent trigger words or separate debug capture streams to be implemented. Signed-off-by:
Stuart Henderson <stuarth@opensource.cirrus.com> Signed-off-by:
-
- 08 Aug, 2018 2 commits
-
-
Richard Fitzgerald authored
Instead of harcoding that a core must always be called "DSPn" add a name member to struct wm_adsp so that the owning codec driver can provide a custom name. This allows for re-use of the wm_adsp driver with parts where the processing cores are named differently. If no name is provided the default DSPn name is used. Signed-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by:
-
Richard Fitzgerald authored
To allow for more flexibility in naming of DSP-type cores move the creation of the firmware controls to the codec drivers instead of having a hardcoded list in wm_adsp. Signed-off-by:
-
- 16 Feb, 2018 1 commit
-
-
Richard Fitzgerald authored
base and sysclk_reg should be unsigned int, as that is what regmap takes as a register address. sysclk_mask is used to mask unsigned register values so should be unsigned. sysclk_shift is a shift value so is not allowed to be negative. Signed-off-by:
-
- 14 Feb, 2018 1 commit
-
-
Kuninori Morimoto authored
Now we can replace Codec to Component. Let's do it. Because there are many drivers which are using arizona, we need to update these all related drivers in same time. Otherwise compile error/warning happen Note: cs47l24 xxx_codec_xxx() -> xxx_component_xxx() .idle_bias_off = 1 -> .idle_bias_on = 0 .ignore_pmdown_time = 0 -> .use_pmdown_time = 1 - -> .endianness = 1 - -> .non_legacy_dai_naming = 1 wm5102 xxx_codec_xxx() -> xxx_component_xxx() .idle_bias_off = 1 -> .idle_bias_on = 0 .ignore_pmdown_time = 0 -> .use_pmdown_time = 1 - -> .endianness = 1 - -> .non_legacy_dai_naming = 1 wm5110 xxx_codec_xxx() -> xxx_component_xxx() .idle_bias_off = 1 -> .idle_bias_on = 0 .ignore_pmdown_time = 0 -> .use_pmdown_time = 1 - -> .endianness = 1 - -> .non_legacy_dai_naming = 1 wm8997 xxx_codec_xxx() -> xxx_component_xxx() .idle_bias_off = 1 -> .idle_bias_on = 0 .ignore_pmdown_time = 0 -> .use_pmdown_time = 1 - -> .endianness = 1 - -> .non_legacy_dai_naming = 1 wm8998 xxx_codec_xxx() -> xxx_component_xxx() .idle_bias_off = 1 -> .idle_bias_on = 0 .ignore_pmdown_time = 0 -> .use_pmdown_time = 1 - -> .endianness = 1 - -> .non_legacy_dai_naming = 1 Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by:
-
- 05 Apr, 2017 2 commits
-
-
Mayuresh Kulkarni authored
Newer ADSP2V2 codecs include a memory protection unit that can be set to trap illegal accesses. When enabling an ADSPV2 core we must configure the memory region traps so that the firmware can access its own memory. Signed-off-by:
Mayuresh Kulkarni <mkulkarni@opensource.wolfsonmicro.com> Signed-off-by:
Nikesh Oswal <Nikesh.Oswal@wolfsonmicro.com> Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by:
-
Richard Fitzgerald authored
Adds support for ADSP2V2 cores. Primary differences are that they use a 32-bit register map compared to the 16-bit register map of ADSP2V1, and there are some changes to clocking control. Signed-off-by:
-
- 06 Jan, 2017 1 commit
-
-
Charles Keepax authored
As requirements to bring up audio paths are continuous getting tighter and the DSP download to most ADSP devices happens over an external bus it can become an important factor in the path bring up time. As such sometimes it is a reasonable trade off to download the firmware ahead of when it will be required and take a small hit on power consumption for keeping the core powered up. This "preloading" adds an additional control for each DSP core "DSPx Preload Switch" that when set to true will power up the DSP core and download the firmware currently selected in the "DSPx Firmware" control. Whilst the core is preloaded the current firmware can not be changed and the CODEC will be kept powered up and SYSCLK held on. Although future improvements may allow the SYSCLK to be powered down as well because the hardware only requires SYSCLK whilst the download is actually taking place, but this is not covered in this series. Signed-off-by:
-
- 29 Nov, 2016 1 commit
-
-
Charles Keepax authored
Functions are given external linkage by default making the extern's unnecessary, as such remove them. Signed-off-by:
-
- 22 Nov, 2016 1 commit
-
-
Richard Fitzgerald authored
We were adding firmware controls as card controls (using snd_soc_add_codec_controls). The DSP is part of a specific codec so we should be adding them as codec controls. Adding as codec controls also means that if the codec has a name_prefix it will be added to the control name, which won't happen when adding as a card control. As that was the only use of the card pointer in struct wm_adsp it can be removed. For ADSP2 codecs a wm_adsp2_codec_probe() was added since the original control handling was written, and that's the logical place to store a pointer to the codec rather than delaying it until the codec is powered-up. For ADSP1 we don't use a codec_probe() stage so the codec pointer initialization replaces the original card pointer initialization in wm_adsp1_event(). Signed-off-by:
-
- 26 Sep, 2016 1 commit
-
-
Charles Keepax authored
The booting process for the DSP is clearly separated into two parts, the preloader brings up the core and downloads code, then the main widget starts the code actually executing. However the shutdown sequence is all handled with the main widget. To allow the preloading to be run independently of the main audio bring up it makes sense, and is generally just cleaner, for the preloader widget to shutdown those things it initialised. This patch moves the appropriate parts of the shutdown process into the preloader widget. Signed-off-by:
-
- 24 Sep, 2016 2 commits
-
-
Charles Keepax authored
Currently the DSP loading is split into two widgets, the preloader that is a snd_soc_dapm_dai_link widget which starts a thread to download the firmware, and the DSP itself which is a snd_soc_dapm_out_drv and synchronises the thread back in to the DAPM sequence. This allows the firmware download to be overlapped with the rest of the path bring up. The use of a snd_soc_dapm_dai_link widget requires the preloader to be part of the audio path in DAPM, really a supply widget is a better fit for the preloader. The preloader is something that needs to be done for the DSP to function, not a part of the audio path itself. This change makes the DSP preloader widget a supply widget, which as well as probably being a better fit will also make it much simpler to power up the preloader widget to trigger firmware download to the core independently of the audio path coming up. Signed-off-by:
-
Charles Keepax authored
Currently the wm_adsp driver has a flag that indicates the DSP is "running", this flag is used to gate access to the hardware. However this flag is actually set in the firmware download thread after the firmware has been downloaded, but this is before the core is actually started running, so really it currently indicates that the core has been booted and is perhaps running. This patch clearly separates out the concepts of booted (firmware is downloaded) and running (code is executing on the DSP) within the wm_adsp driver. Signed-off-by:
-
- 30 May, 2016 1 commit
-
-
Charles Keepax authored
The DSP uses an IRQ to indicate data is available on the compressed stream. For voice trigger use-cases the first such IRQ can be considered an indication that the user has spoken the key phrase triggering the firmware. Provide a means for the ADSP code to communicate back to the calling driver whether an IRQ should be considered as trigger event or not. Signed-off-by:
-
- 27 Apr, 2016 1 commit
-
-
Richard Fitzgerald authored
The patch adds a wm_adsp2_remove() function to ensure that memory is freed when the driver is unloaded or shut down. Signed-off-by:
-
- 28 Jan, 2016 1 commit
-
-
Charles Keepax authored
The ADSP code should be agnostic of which CODEC it runs upon, currently there is only one remaining part of the implementation that doesn't follow this. When the DSP is booted on ADSP2 we read ARIZONA_SYSTEM_CLOCK_1 and use that to set the initial speed for the DSP clock. This patch factors that out into CODEC specific code, leaving the ADSP code entirely CODEC agnostic. Signed-off-by:
-
- 06 Jan, 2016 2 commits
-
-
Charles Keepax authored
Data is read in blocks of up to one fragment is size from the circular buffer on the DSP and is re-packed to remove the padding byte that exists in the DSP memory map. Signed-off-by:
-
Charles Keepax authored
Here support is added for responding to DSP IRQs that are used to indicate data being available on the DSP. The idea is that we check the amount of data available upon receipt of an IRQ and on subsequent calls to the pointer callback we recheck once less than one fragment is available (to avoid excessive SPI traffic), if there is truely less than one fragment available we ack the last IRQ and wait for a new one. Signed-off-by:
-
- 23 Dec, 2015 3 commits
-
-
Charles Keepax authored
The stream is created whilst the compressed stream is opened and a buffer is created when the DSP powers up. It is necessary at a point once both the DSP has powered up and the the stream has been opened to connect a stream to a buffer on the DSP. This is done in the trigger callback as this is after the DSP has been powered and obviously the stream must be open. Note that whilst the connect is currently trivial it is expected that this will get more complex when support for multiple buffers/streams per DSP is added. Signed-off-by:
-
Charles Keepax authored
Add code that locates and initialises the buffer of compressed data on the DSP if the firmware supported compressed data capture. The buffer struct (wm_adsp_compr_buf) is kept separate from the stream struct (wm_adsp_compr) this will allow much easier support of multiple streams of data from the one DSP in the future, although support for this will not be added in this patch chain. Signed-off-by:
-
Charles Keepax authored
Allow user-space to open a compressed stream, although no data will be passed yet, as part of this adding the ability to define supported capabilities per firmware and check these match the stream being opened. Signed-off-by:
-
- 12 Dec, 2015 2 commits
-
-
Charles Keepax authored
Signed-off-by:
-
Charles Keepax authored
Most events around the DSP just need to be locked to ensure that the DSP can't change power state whilst they are happening. This includes the debugfs entries and this will make sorting the rest of the locking simpler. Signed-off-by:
-
- 04 Oct, 2015 1 commit
-
-
Viresh Kumar authored
Its a bit odd that debugfs_create_bool() takes 'u32 *' as an argument, when all it needs is a boolean pointer. It would be better to update this API to make it accept 'bool *' instead, as that will make it more consistent and often more convenient. Over that bool takes just a byte. That required updates to all user sites as well, in the same commit updating the API. regmap core was also using debugfs_{read|write}_file_bool(), directly and variable types were updated for that to be bool as well. Signed-off-by:Viresh Kumar <viresh.kumar@linaro.org> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 Jun, 2015 1 commit
-
-
Richard Fitzgerald authored
The rate controls are codec-specific, it's not possible to generically say what the range or the meaning of each control is (or even if they exist at all) - that depends on the particular codec. This is currently being handled for Arizona codecs by putting an Arizona-specific table of controls inside the wm_adsp driver. This creates a dependency between wm_adsp and arizona.c, and is an awkward solution if the ADSP is used in another family of codecs Fix this by moving the Arizona-specific rate controls into the Arizona codec drivers. Signed-off-by:
-
- 11 Jun, 2015 3 commits
-
-
Richard Fitzgerald authored
This patch adds some debugfs nodes to get information about the currently running firmware. Signed-off-by:
-
Richard Fitzgerald authored
Now that we have a codec_probe stage initialization in the wm_adsp driver, we can make the wm_adsp driver create its own ALSA controls instead of having that responsibility pushed to every codec driver. Signed-off-by:
-
Richard Fitzgerald authored
Currently the only init function in wm_adsp is called by the codec driver early in its probe before the codec has been registered with SOC. This patch adds stubs for the codec_probe and codec_remove stages and calls them from WM5102 and WM5110 codec drivers. This allows us to hang anything that needs setup during the codec probe stage off these functions without further modification of the codec drivers. Signed-off-by:
-
- 02 Jun, 2015 1 commit
-
-
Richard Fitzgerald authored
In theory the ADSP driver should not need to know anything about the codec it is part of. But the WM5102 needs DVFS control based on ADSP clocking speed. This was being handled by bundling part of the knowledge of this into the ADSP driver. This change moves this handling out of the ADSP driver and into the WM5102 driver. Signed-off-by:
-
- 27 Apr, 2015 3 commits
-
-
Charles Keepax authored
Revision one of the file format includes new algorithm and coefficient blocks which provide additional information about the controls exported by the firmware. This patch updates the processing to handle this version of the file format. Note that whilst this version of the format adds support for specifying a name for the control through the firmware file this has not been used and to keep compatibility with existing deployments no changes to the firmware control naming are made by this patch. Signed-off-by:
-
Charles Keepax authored
The algorithm region information in the firmware doesn't contain a length field, explicitly pass this to the create_control function rather than bundling into wm_adsp_alg_region. Signed-off-by:
-
Charles Keepax authored
We have wm_adsp_region, wm_adsp_alg_region, and wmfw_region, the variables for which are all frequently called region, this can get quite confusing when reviewing the code especially given some functions are quite long. Consistently use mem for wm_adsp_regions, alg_region for wm_adsp_alg_region and region for wmfw_region. Additionally, we use a mix of adsp and dsp for pointers to the wm_adsp structure standardise this on dsp. Finally, we use algs to refer to the number of algorithms quite frequently, change this to the more descriptive n_algs. Signed-off-by:
-
- 08 Jan, 2014 2 commits
-
-
Charles Keepax authored
Move the start of booting the DSP to earlier in the DAPM process, and move the final starting of the DSP to later in the DAPM process. This allows us to overlap some of the processing with other components of the system being brought up. Signed-off-by:
Mark Brown <broonie@linaro.org>
-
Charles Keepax authored
Move the ADSP2 boot proceedure into a work structure in preparation for running it asynchronously with the reset of the audio path bring up. Signed-off-by:
-
- 01 Aug, 2013 1 commit
-
-
Dimitris Papastamos authored
No need to hold on to the `codec' pointer. We can use the `dsp' pointer and grab all the information we need from there. This makes the parameters for the functions a bit more sane and idiomatic. Signed-off-by:
Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by:
-
- 29 Jul, 2013 1 commit
-
-
Dimitris Papastamos authored
Get rid off the wm_coeff struct and the wm_coeff_add_kcontrol() function. We are now using the snd_soc_card_kcontrol() function to get the kcontrol pointers. No need to call into ALSA code to register the kcontrols. Signed-off-by:
-
- 19 Jun, 2013 1 commit
-
-
Lars-Peter Clausen authored
Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
- 12 May, 2013 1 commit
-
-
Dimitris Papastamos authored
Add initial support for runtime tuning for the ADSP cores. This is achieved by exposing the coefficient configuration blocks as ALSA binary controls. The current code assumes that no controls on the DSP are volatile. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com>
-
- 29 Mar, 2013 1 commit
-
-
Mark Brown authored
Now that we have regular register mapped controls we should be splitting the control sets for ADSP1 and ADSP2 as the register maps are not identical. Do that. Signed-off-by:
-
