1. 01 10月, 2019 1 次提交
  2. 03 5月, 2018 1 次提交
  3. 26 4月, 2018 1 次提交
    • F
      ASoC: fsl_ssi: Use u32 variable type when using regmap_read() · 671f8204
      Fabio Estevam 提交于
      Convert the sisr and sisr2 variable types to u32 to avoid the following
      sparse warnings:
      
      sound/soc/fsl/fsl_ssi.c:391:42: warning: incorrect type in argument 3 (different base types)
      sound/soc/fsl/fsl_ssi.c:391:42:    expected unsigned int *val
      sound/soc/fsl/fsl_ssi.c:391:42:    got restricted __be32 *<noident>
      sound/soc/fsl/fsl_ssi.c:393:17: warning: restricted __be32 degrades to integer
      sound/soc/fsl/fsl_ssi.c:393:15: warning: incorrect type in assignment (different base types)
      sound/soc/fsl/fsl_ssi.c:393:15:    expected restricted __be32 [usertype] sisr2
      sound/soc/fsl/fsl_ssi.c:393:15:    got unsigned int
      sound/soc/fsl/fsl_ssi.c:396:50: warning: incorrect type in argument 3 (different base types)
      sound/soc/fsl/fsl_ssi.c:396:50:    expected unsigned int [unsigned] val
      sound/soc/fsl/fsl_ssi.c:396:50:    got restricted __be32 [usertype] sisr2
      sound/soc/fsl/fsl_ssi.c:398:42: warning: incorrect type in argument 2 (different base types)
      sound/soc/fsl/fsl_ssi.c:398:42:    expected unsigned int [unsigned] [usertype] sisr
      sound/soc/fsl/fsl_ssi.c:398:42:    got restricted __be32 [addressable] [usertype] sisr
      
      In other places where regmap_read() is used a u32 variable is passed
      to store the register read value, so do the same here as well.
      
      regmap API already takes care of endianness, so the usage of u32 is safe.
      Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      671f8204
  4. 12 4月, 2018 1 次提交
    • N
      ASoC: fsl_ssi: Fix mode setting when changing channel number · fac8a5a5
      Nicolin Chen 提交于
      This is a partial revert (in a cleaner way) of commit ebf08ae3
      ("ASoC: fsl_ssi: Keep ssi->i2s_net updated") to fix a regression
      at test cases when switching between mono and stereo audio.
      
      The problem is that ssi->i2s_net is initialized in set_dai_fmt()
      only, while this set_dai_fmt() is only called during the dai-link
      probe(). The original patch assumed set_dai_fmt() would be called
      during every playback instance, so it failed at the overriding use
      cases.
      
      This patch adds the local variable i2s_net back to let regular use
      cases still follow the mode settings from the set_dai_fmt().
      
      Meanwhile, the original commit of keeping ssi->i2s_net updated was
      to make set_tdm_slot() clean by checking the ssi->i2s_net directly
      instead of reading SCR register. However, the change itself is not
      necessary (or even harmful) because the set_tdm_slot() might fail
      to check the slot number for Normal-Mode-None-Net settings while
      mono audio cases still need 2 slots. So this patch can also fix it.
      And it adds an extra line of comments to declare ssi->i2s_net does
      not reflect the register value but merely the initial setting from
      the set_dai_fmt().
      Reported-by: NMika Penttilä <mika.penttila@nextfour.com>
      Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
      Tested-by: NMika Penttilä <mika.penttila@nextfour.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      fac8a5a5
  5. 21 2月, 2018 17 次提交
  6. 12 2月, 2018 1 次提交
    • F
      ASoC: fsl_ssi: Use 'const _be *' type for iprop · da18bcf7
      Fabio Estevam 提交于
      The 'iprop' variable is passed as an argument to the be32_to_cpup()
      function, which expects a 'const _be *' type.
      
      Change the iprop variable type so that the following build warnings
      with W=1 are gone:
      
      sound/soc/fsl/fsl_ssi.c:1463:48: warning: incorrect type in argument 1 (different base types)
      sound/soc/fsl/fsl_ssi.c:1463:48:    expected restricted __be32 const [usertype] *p
      sound/soc/fsl/fsl_ssi.c:1463:48:    got unsigned int const [usertype] *[assigned] iprop
      Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      da18bcf7
  7. 19 12月, 2017 11 次提交
  8. 29 11月, 2017 3 次提交
    • M
      ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture · 10582635
      Maciej S. Szmigiero 提交于
      When testing AC'97 capture on UDOO board (currently the only user of
      fsl_ssi driver in the AC'97 mode) it become obvious that there is a massive
      distortion above certain, small input signal.
      
      This problem has been traced to silicon errata ERR003778:
      "In AC97, 16-bit mode, received data is shifted by 4-bit locations" that
      has "No fix scheduled".
      This errata suggests a workaround of doing a 4-bit shift back in SDMA
      script for this specific operation mode, however our SDMA scripts are
      shared between various SoC peripherals so we can't really modify them.
      
      There is a simple way to avoid this problem, however, that is to disallow
      recording in 16-bit mode and only support it in AC'97-native 20-bit mode.
      We have to use a 4-byte format for this since SSI FIFOs do not allow 3-byte
      accesses (and these aren't supported by imx-sdma driver anyway).
      With this change the capture distortion is gone.
      
      We can also add this format as an additional one supported for playback,
      using this opportunity to make sure that we use CPU-endian-native formats
      in AC'97 mode as we already do in I2S mode.
      
      There is no problem in using different bit widths in playback and capture
      in AC'97 mode so allow this, too.
      Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      10582635
    • M
      ASoC: fsl_ssi: only enable proper channel slots in AC'97 mode · 01ca4851
      Maciej S. Szmigiero 提交于
      We need to make sure that only proper channel slots (in SACCST register)
      are enabled at playback start time since some AC'97 CODECs (like VT1613 on
      UDOO board) were observed requesting via SLOTREQ spurious ones just after
      an AC'97 link is started but before the CODEC is configured by its driver.
      When a bit for some channel slot is set in a SLOTREQ request then SSI sets
      the relevant bit in SACCST automatically, which then 'sticks' until it is
      manually unset.
      The SACCST register is not writable directly, we have to use SACCDIS and
      SACCEN registers to configure it instead (these aren't normal registers:
      writing a '1' bit at some position in SACCEN sets the relevant bit in
      SACCST; SACCDIS operates in a similar way but allows unsetting bits in
      SACCST).
      
      Theoretically, this should be necessary only for the very first playback
      but since some CODECs are so untrustworthy and extra channel slots enabled
      mean ruined playback let's play safe here and make sure that no extra
      slots are enabled in SACCST every time a playback is started.
      Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
      Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      01ca4851
    • M
      ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode · c997a92a
      Maciej S. Szmigiero 提交于
      In AC'97 mode we configure and start SSI RX / TX on probe path via
      a call to _fsl_ssi_set_dai_fmt() function.
      We don't need to call this function again later and in fact don't want to
      do it since this function temporarily sets STCR, SRCR and SCR to some
      intermediate values.
      Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
      Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      c997a92a
  9. 28 11月, 2017 3 次提交
  10. 19 9月, 2017 1 次提交
    • N
      ASoC: fsl_ssi: Caculate bit clock rate using slot number and width · b0a7043d
      Nicolin Chen 提交于
      The set_sysclk() now is used to override the output bit clock rate.
      But this is not a common way to implement a set_dai_sysclk(). And
      this creates a problem when a general machine driver (simple-card
      for example) tries to do set_dai_sysclk() by passing an input clock
      rate for the baud clock instead of setting the bit clock rate as
      fsl_ssi driver expected.
      
      So this patch solves this problem by firstly removing set_sysclk()
      since the hw_params() can calculate the bit clock rate. Secondly,
      in order not to break those TDM use cases which previously might
      have been using set_sysclk() to override the bit clock rate, this
      patch changes the driver to calculate the bit clock rate using the
      slot number and the slot width from the via set_tdm_slot().
      
      The patch also removes an obsolete comment of the dir parameter.
      Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      b0a7043d