1. 14 5月, 2014 1 次提交
  2. 07 5月, 2014 1 次提交
  3. 06 5月, 2014 1 次提交
  4. 03 5月, 2014 6 次提交
  5. 24 4月, 2014 1 次提交
  6. 23 4月, 2014 2 次提交
    • W
      ASoC: Intel: Fix audio crash due to race condition in stream deletion · d132cb0a
      Wenkai Du 提交于
      There is a race between sst_byt_stream_free() and sst_byt_get_stream()
      if sst_byt_get_stream() called from sst_byt_irq_thread() context is
      accessing the byt->stream_list while a stream is deleted from the list.
      
      A stream is added to byt->stream_list in sst_byt_stream_new() and deleted in
      sst_byt_stream_free(). sst_byt_get_stream() is always protected by
      sst->spinlock, but the stream addition and deletion are not protected.
      
      The patch adds spinlock to both stream addition and deletion.
      
      [Jarkko: Same fix added to sst-haswell-ipc.c too]
      Signed-off-by: NWenkai Du <wenkai.du@intel.com>
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      d132cb0a
    • W
      ASoC: Intel: Fix audio crash due to negative address offset · 95e9ee92
      Wenkai Du 提交于
      There were occasional ADSP crash during reboot testing:
      
      [   11.883364] BUG: unable to handle kernel paging request at ffffc90121700000
      [   11.883380] IP: [<ffffffffc024d8bc>] sst_module_insert_fixed_block+0x24f/0x26d [snd_soc_sst_dsp]
      [   11.883397] PGD 7800b067 PUD 0
      [   11.883405] Oops: 0002 [#1] SMP
      [   11.886418] gsmi: Log Shutdown Reason 0x03
      
      The virtual address, ffffc90121700000, was out of range. The virtual
      address is calculated by adding LPE base address with an offset:
      
      sst_memcpy32(dsp->addr.lpe + data->offset, data->data, data->size);
      
      The offset is calculated in sst_byt_parse_module, by subtraction of
      two virtual addresses dsp->addr.fw_ext and dsp->addr.lpe:
      
      block_data.offset = block->ram_offset + (dsp->addr.fw_ext - dsp->addr.lpe);
      
      These virtual addresses are assigned by kernel from ioremap:
      
      sst->addr.lpe = ioremap(pdata->lpe_base, pdata->lpe_size);
      sst->addr.fw_ext = ioremap(pdata->fw_base, pdata->fw_size);
      
      In current driver code, offset is defined as unsigned int32:
      
      struct sst_module_data {
      ...
      	u32 offset;		/* offset in FW file */
      };
      
      Most of the time kernel assigned virtual addresses with addr.fw_ext
      greater than addr.lpe. But sometimes it was the other way round.
      
      Fix the problem by declaring offset as signed int32_t.
      Signed-off-by: NWenkai Du <wenkai.du@intel.com>
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      95e9ee92
  7. 19 4月, 2014 2 次提交
  8. 22 3月, 2014 2 次提交
  9. 13 3月, 2014 1 次提交
    • S
      ASoC: Intel: don't select RT5640 if !I2C · f410d5c9
      Stephen Warren 提交于
      The rt5640 driver won't compile without I2C enabled. Hence, the Intel
      Haswell and Baytrail+RT5640 ASoC drivers must also depend on I2C, since
      these select RT5640.
      
      This solves:
      sound/soc/codecs/rt5640.c:2220:1: warning: data definition has no type or storage class [enabled by default]
      sound/soc/codecs/rt5640.c:2220:1: error: type defaults to ‘int’ in declaration of ‘module_i2c_driver’ [-Werror=implicit-int]
      sound/soc/codecs/rt5640.c:2220:1: warning: parameter names (without types) in function declaration [enabled by default]
      sound/soc/codecs/rt5640.c:2210:26: warning: ‘rt5640_i2c_driver’ defined but not used [-Wunused-variable]
      Reported-by: NJim Davis <jim.epost@gmail.com>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      f410d5c9
  10. 07 3月, 2014 3 次提交
  11. 06 3月, 2014 1 次提交
  12. 26 2月, 2014 7 次提交
  13. 25 2月, 2014 7 次提交
  14. 22 2月, 2014 5 次提交