1. 24 Apr, 2022 4 commits
    • Hans Verkuil's avatar
      media: cec: correctly pass on reply results · f9d0ecbf
      Hans Verkuil authored
      The results of non-blocking transmits were not correctly communicated
      to userspace.
      
      Specifically:
      
      1) if a non-blocking transmit was canceled, then rx_status wasn't set to 0
         as it should.
      2) if the non-blocking transmit succeeded, but the corresponding reply
         never arrived (aborted or timed out), then tx_status wasn't set to 0
         as it should, and rx_status was hardcoded to ABORTED instead of the
         actual reason, such as TIMEOUT. In addition, adap->ops->received() was
         never called, so drivers that want to do message processing themselves
         would not be informed of the failed reply.
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      f9d0ecbf
    • Hans Verkuil's avatar
      media: cec: abort if the current transmit was canceled · 590a8e56
      Hans Verkuil authored
      If a transmit-in-progress was canceled, then, once the transmit
      is done, mark it as aborted and refrain from retrying the transmit.
      
      To signal this situation the new transmit_in_progress_aborted field is
      set to true.
      
      The old implementation would just set adap->transmitting to NULL and
      set adap->transmit_in_progress to false, but on the hardware level
      the transmit was still ongoing. However, the framework would think
      the transmit was aborted, and if a new transmit was issued, then
      it could overwrite the HW buffer containing the old transmit with the
      new transmit, leading to garbled data on the CEC bus.
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      590a8e56
    • Hans Verkuil's avatar
      media: cec: call enable_adap on s_log_addrs · 3813c932
      Hans Verkuil authored
      Don't enable/disable the adapter if the first fh is opened or the
      last fh is closed, instead do this when the adapter is configured
      or unconfigured, and also when we enter Monitor All or Monitor Pin
      mode for the first time or we exit the Monitor All/Pin mode for the
      last time.
      
      However, if needs_hpd is true, then do this when the physical
      address is set or cleared: in that case the adapter typically is
      powered by the HPD, so it really is disabled when the HPD is low.
      This case (needs_hpd is true) was already handled in this way, so
      this wasn't changed.
      
      The problem with the old behavior was that if the HPD goes low when
      no fh is open, and a transmit was in progress, then the adapter would
      be disabled, typically stopping the transmit immediately which
      leaves a partial message on the bus, which isn't nice and can confuse
      some adapters.
      
      It makes much more sense to disable it only when the adapter is
      unconfigured and we're not monitoring the bus, since then you really
      won't be using it anymore.
      
      To keep track of this store a CEC activation count and call adap_enable
      only when it goes from 0 to 1 or back to 0.
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      3813c932
    • Yihao Han's avatar
      media: meson-ir-tx: remove superfluous dev_err() · 82b4737f
      Yihao Han authored
      Remove dev_err() messages after platform_get_irq*() failures.
      platform_get_irq() already prints an error.
      
      Generated by: scripts/coccinelle/api/platform_get_irq.cocci
      Signed-off-by: default avatarYihao Han <hanyihao@vivo.com>
      Reviewed-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      82b4737f
  2. 18 Apr, 2022 26 commits
  3. 17 Apr, 2022 10 commits