1. 02 Dec, 2013 1 commit
    • Oskar Schirmer's avatar
      ASoC: fsl: imx-pcm-fiq: remove bogus period delta calculation · d6437c14
      Oskar Schirmer authored
      Originally snd_hrtimer_callback() used iprtd->period_time for
      some jiffies based estimation to determine the right moment
      to call snd_pcm_period_elapsed(). As timer drifts may well be a
      problem, this was changed in commit b4e82b5b to be based
      on buffer transmission progress, using iprtd->offset and
      runtime->buffer_size to calculate the amount of data since last
      period had elapsed.
      
      Unfortunately, iprtd->offset counts in bytes, while
      runtime->buffer_size counts frames, so adding these to find some
      delta is like comparing apples and oranges, and eventually results
      in negative delta values every now and then. This is no big harm,
      because it simply causes snd_pcm_period_elapsed() being called
      more often than necessary, as negative delta is taken for a
      large unsigned value by implicit conversion rule.
      Nonetheless, the calculation is broken, so one would replace
      the runtime->buffer_size by its equivalent in bytes.
      
      But then, there are chances snd_pcm_period_elapsed() is called
      late, because calculating the moment for the elapsed period
      into delta is based against the iprtd->last_offset, which is not
      necessarily the first byte of the period in question, but some
      random byte which the FIQ handler left us with in r8/r9 by
      accident. Again, negative impact is low, as there are plenty of
      periods already prefilled with data, and snd_pcm_period_elapsed()
      will probably be called latest when the following period is
      reached. However, the calculation is conceptually broken, and we
      are best off removing the clever stuff altogether.
      
      snd_pcm_period_elapsed() is now simply called once everytime
      snd_hrtimer_callback() is run, which may not be most accurate,
      but at least this way we are quite sure we dont miss an end of
      period. There is not much extra effort wasted by superfluous
      calls to snd_pcm_period_elapsed(), as the timer frequency
      closely matches the period size anyway.
      Signed-off-by: default avatarOskar Schirmer <oskar@scara.com>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      d6437c14
  2. 14 Nov, 2013 1 commit
    • Oskar Schirmer's avatar
      ASoC: fsl: imx-pcm-fiq: omit fiq counter to avoid harm in unbalanced situations · fc7dc61d
      Oskar Schirmer authored
      Unbalanced calls to snd_imx_pcm_trigger() may result in endless
      FIQ activity and thus provoke eternal sound. While on the first glance,
      the switch statement looks pretty symmetric, the SUSPEND/RESUME
      pair is not: the suspend case comes along snd_pcm_suspend_all(),
      which for fsl/imx-pcm-fiq is called only at snd_soc_suspend(),
      but the resume case originates straight from the SNDRV_PCM_IOCTL_RESUME.
      This way userland may provoke an unbalanced resume, which might cause
      the fiq_enable counter to increase and never return to zero again,
      so eventually imx_pcm_fiq is never disabled.
      
      Simply removing the fiq_enable will solve the problem, as long as
      one never goes play and capture game simultaneously, but beware
      trying both at once, the early TRIGGER_STOP will cut off the other
      activity prematurely. So now playing and capturing is scrutinized
      separately, instead of by counting.
      Signed-off-by: default avatarOskar Schirmer <oskar@scara.com>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Cc: stable@vger.kernel.org
      fc7dc61d
  3. 04 Nov, 2013 18 commits
  4. 01 Nov, 2013 8 commits
  5. 31 Oct, 2013 4 commits
  6. 30 Oct, 2013 7 commits
  7. 29 Oct, 2013 1 commit