1. 15 Dec, 2017 3 commits
    • Steve Longerbeam's avatar
      media: staging/imx: get CSI bus type from nearest upstream entity · bf3cfaa7
      Steve Longerbeam authored
      The imx-media driver currently supports a device tree graph of
      limited complexity. This patch is a first step in allowing imx-media
      to work with more general OF graphs.
      
      The CSI subdevice assumes the originating upstream subdevice (the
      "sensor") is connected directly to either the CSI mux or the MIPI
      CSI-2 receiver. But for more complex graphs, the sensor can be distant,
      with possible bridge entities in between. Thus the sensor's bus type
      could be quite different from what is entering the CSI. For example
      a distant sensor could have a parallel interface, but the stream
      entering the i.MX is MIPI CSI-2.
      
      To remove this assumption, get the entering bus config from the entity
      that is directly upstream from either the CSI mux, or the CSI-2 receiver.
      If the CSI-2 receiver is not in the enabled pipeline, the bus type to the
      CSI is parallel, otherwise the CSI is receiving MIPI CSI-2.
      
      Note that we can't use the direct upstream source connected to CSI
      (which is either the CSI mux or the CSI-2 receiver) to determine
      bus type. The bus entering the CSI from the CSI-2 receiver is a 32-bit
      parallel bus containing the demultiplexed MIPI CSI-2 virtual channels.
      But the CSI and its IDMAC channels must be configured based on whether
      it is receiving data from the CSI-2 receiver or from the CSI mux's
      parallel interface pins.
      
      The function csi_get_upstream_endpoint() is used to find this
      endpoint. It makes use of a new utility function
      imx_media_find_upstream_pad(), that if given a grp_id of 0, will
      return the closest upstream pad from start_entity.
      
      With these changes, imx_media_find_sensor() is no longer used and
      is removed. As a result there is also no longer a need to identify
      any sensor or set the sensor subdev's group id as a method to search
      for it. So IMX_MEDIA_GRP_ID_SENSOR is removed. Also the video-mux group
      id IMX_MEDIA_GRP_ID_VIDMUX was never used so that is removed as well.
      The remaining IMX_MEDIA_GRP_ID_* definitions are entities internal
      to the i.MX.
      
      Another use of imx_media_find_sensor() in the CSI was to call the
      sensor's g_skip_frames op to determine if a delay was needed before
      enabling the CSI at stream on. If necessary this will have to be
      re-addressed at a later time.
      Signed-off-by: default avatarSteve Longerbeam <steve_longerbeam@mentor.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      bf3cfaa7
    • Arnd Bergmann's avatar
      media: dvb-frontends: fix i2c access helpers for KASAN · 3cd890db
      Arnd Bergmann authored
      A typical code fragment was copied across many dvb-frontend drivers and
      causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7:
      
      drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
      drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
      drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
      drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
      drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
      
      gcc-8 now solves this by consolidating the stack slots for the argument
      variables, but on older compilers we can get the same behavior by taking
      the pointer of a local variable rather than the inline function argument.
      
      Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      3cd890db
    • Arnd Bergmann's avatar
      media: r820t: fix r820t_write_reg for KASAN · 16c3ada8
      Arnd Bergmann authored
      With CONFIG_KASAN, we get an overly long stack frame due to inlining
      the register access functions:
      
      drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
      drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
      
      This is caused by a gcc bug that has now been fixed in gcc-8.
      To work around the problem, we can pass the register data
      through a local variable that older gcc versions can optimize
      out as well.
      
      Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      16c3ada8
  2. 14 Dec, 2017 37 commits