Skip to content

L
linux
Switch branch/tag
  1. 31 Oct, 2014 14 commits
  3. 30 Oct, 2014 4 commits
    • Jie Yang's avatar
      ASoC: Intel: Work around to fix HW D3 potential crash issue · 0d2135ec
      Jie Yang authored 
      When using clock gatings to save power, there are some known issues:
1. core clock gating (DCLCGE) must be disabled during D0 and D3 entry
and updating SRAM banks (VDRTCTL0).
2. DSP trunk clock gating (DTCGE) can cause FW crashes, disable it in D0.

To align with the new W/A flow from FW team, we must set VDRTCTL0.D3PGD
to 1 (D3 power gating disabled) at first startup and keep it all the time.
ADSP will be in D0 on first boot by BIOS part of WA. Required delays must
be preserved (waiting for HW to stabilize, after enabling CCG, changing
SRAM PG, D3PG).

D3->D0:
1. Disable core clock gating (VDRTCTL2.DCLCGE = 0)
2. Enable other CG apart from DTCG and DCLCG (VDRTCTL2. DCLCGE and DTCGE = 0)
3. Disable D3PG (VDRTCTL0.D3PGD = 1)
4. Power up necessary SRAM and wait at least for 18 clock cycles for every
bank you have powered up
5. Set D0 state(PMCS.PS = 0), wait for HW
6. Restore MCLK (clkctl.smos, disabled in D3 entry point 4)
7. Stall and reset core, set CSR
8. Enable core clock gating (VDRTCTL2.DCLCGE = 1), delay 50 us
9. Unreset core
10.Load FW, configure PLL and other necessary things
11.Unstall core

Changing SRAM PG during D0:
1. Disable core clock gating (VDRTCTL2.DCLCGE = 0)
2. Set PG mask
3. Wait at least for 18 clock cycles for every bank you have powered up
4. Enable core clock gating, delay 50 us

D0->D3:
1. Disable core clock gating (DCLCGE = 0)
2. Stall and reset core
3. Power down entire SRAM and wait at least for 18 clock cycles for every bank
(Enable SRAM PG (ISRAMPGE = 0x3FF, DSRAMPGE = 0xFFFFF, D3SRAMPGD = 0), remember
about preserving VDRTCTL0.D3PGD = 1)
4. Shutdown PLL, disable MCLK(clkctl.smos = 0), Enable DTCG to save power
5. Set D3 state(PMCS.PS = 3), delay 50 us
6. Enable core clock gating, delay 50 us
Signed-off-by: default avatarJie Yang <yang.jie@intel.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      0d2135ec
    • Liam Girdwood's avatar
      ASoC: Intel: fix build with runtime PM disabled. · 35e03a88
      Liam Girdwood authored 
      Fix the following errors:

All error/warnings:

>> sound/soc/intel/sst-haswell-pcm.c:1168:13: error: 'hsw_pcm_prepare' undeclared here (not in a function)
     .prepare = hsw_pcm_prepare,
                ^
>> sound/soc/intel/sst-haswell-pcm.c:1169:14: error: 'hsw_pcm_complete' undeclared here (not in a function)
     .complete = hsw_pcm_complete,
                 ^
Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: default avatarLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      35e03a88
    • Liam Girdwood's avatar
      ASoC: Intel: Add debug output when boot fails. · b891f62f
      Liam Girdwood authored 
      Add the debug output from IPCD and IPCX when booting fails.
Signed-off-by: default avatarLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      b891f62f
    • Jie Yang's avatar
      ASoC: Intel: Fix block is enabled multiple times issue · 35c0a8c0
      Jie Yang authored 
      During FW parsing and loading, block_list_prepare() may
be called for each raw data block copying and this may
made the hsw_block_enable() called mutiple times, which
increase block->users many times. The result of this is
hsw_block_disable() can't power gated the related block
when trying to free the blocks during suspend, and the
power gating status also confused.

Here check the block user status, only calling enable()
for those blocks who has no user yet. Remember that
this works correctlly on current case, where there are
enough SRAM memory so different module won't share a
memory block. For further usage, we may need restructure
the struct sst_mem_block to save the module list who is
using it.
Signed-off-by: default avatarJie Yang <yang.jie@intel.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      35c0a8c0
  5. 29 Oct, 2014 6 commits
  7. 28 Oct, 2014 1 commit
    • Liam Girdwood's avatar
      ASoC: Intel: Make ADSP memory block allocation more generic · e9600bc1
      Liam Girdwood authored 
      Current block allocation is tied to block type and requestor type. Make the
allocation more generic by removing the struct module parameter and adding
a generic block allocator structure. Also pass in the list that the blocks
have to be added too in order to remove dependence on block requestor type.

ASoC: Intel: update scratch allocator to use generic block allocator

Update the scratch allocator to use the generic block allocator and calculate
total scratch buffer size.

ASoC: Intel: Add call to calculate offsets internally within the DSP.

A call to calculate internal DSP memory addresses used to allocate persistent
and scartch buffers.

ASoC: Intel: Add runtime module support.

Add support for runtime module objects that can be created for every FW
module that is parsed from the FW file. This gives a 1:N mapping between
the FW module from file and the runtime instantiations of that module.

We also need to make sure we remove every module and runtime module when
we unload the FW.

ASoC: Intel: Add DMA firmware loading support

Add support for DMA to load firmware modules to the DSP memory blocks.
Two DMA engines are supported, DesignWare and Intel MID.

ASoC: Intel: Add runtime module lookup API call

Add an API to allow quick lookup of runtime modules based on ID.

ASoC: Intel: Provide streams with dynamic module information

Remove the hard coded module paramaters and provide each module with
dynamically generated buffer information for scratch and persistent
buffers.
Signed-off-by: default avatarLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      e9600bc1
  9. 27 Oct, 2014 3 commits
  11. 21 Oct, 2014 5 commits
  13. 20 Oct, 2014 7 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7