1. 18 Dec, 2017 25 commits
  2. 15 Dec, 2017 11 commits
    • Steve Longerbeam's avatar
      media: staging/imx: update TODO · 45267fed
      Steve Longerbeam authored
      Update TODO file:
      
      - Remove TODO info about the OV564x driver, while this still needs
        to be done (add a OV5642 driver or merge with OV5640 driver), it
        is not relevant here.
      
      - Update TODO about methods for retrieving CSI bus config.
      
      - Add some TODO's about OF graph parsing restrictions.
      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>
      45267fed
    • Steve Longerbeam's avatar
      media: staging/imx: reorder function prototypes · e762fe4c
      Steve Longerbeam authored
      Re-order some of the function prototypes in imx-media.h to
      group them correctly by source file. No functional changes.
      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>
      e762fe4c
    • Steve Longerbeam's avatar
      media: staging/imx: convert static vdev lists to list_head · bd9d208a
      Steve Longerbeam authored
      Although not technically necessary because imx-media has only a
      maximum of 8 video devices, and once setup the video device lists
      are static, in anticipation of moving control ineritance to
      v4l2-core, make the vdev lists more generic by converting to
      dynamic list_head's.
      
      After doing that, 'struct imx_media_pad' is now just a list_head
      of video devices reachable from a pad. Allocate an array of list_head's,
      one list_head for each pad, and attach that array to sd->host_priv.
      An entry in the pad lists is of type 'struct imx_media_pad_vdev', and
      points to a video device from the master list.
      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>
      bd9d208a
    • Steve Longerbeam's avatar
      media: staging/imx: remove static subdev arrays · 9f6a0c59
      Steve Longerbeam authored
      For more complex OF graphs, there will be more async subdevices
      registered. Remove the static subdev[IMX_MEDIA_MAX_SUBDEVS] array,
      so that imx-media places no limits on the number of async subdevs
      that can be added and registered.
      
      There were two uses for 'struct imx_media_subdev'. First was to act
      as the async subdev list to be passed to v4l2_async_notifier_register().
      
      Second was to aid in inheriting subdev controls to the capture devices,
      and this is done by creating a list of capture devices that can be reached
      from a subdev's source pad. So 'struct imx_media_subdev' also contained
      a static array of 'struct imx_media_pad' for placing the capture device
      lists at each pad.
      
      'struct imx_media_subdev' has been completely removed. Instead, at async
      completion, allocate an array of 'struct imx_media_pad' and attach it to
      the subdev's host_priv pointer, in order to support subdev controls
      inheritance.
      
      Likewise, remove static async_ptrs[IMX_MEDIA_MAX_SUBDEVS] array.
      Instead, allocate a 'struct imx_media_async_subdev' when forming
      the async list, and add it to an asd_list list_head in
      imx_media_add_async_subdev(). At async completion, allocate the
      asd pointer list and pull the asd's off asd_list for
      v4l2_async_notifier_register().
      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>
      9f6a0c59
    • Steve Longerbeam's avatar
      media: staging/imx: pass fwnode handle to find/add async subdev · 4eef678d
      Steve Longerbeam authored
      Pass the subdev's fwnode_handle to imx_media_find_async_subdev() and
      imx_media_add_async_subdev(), instead of a device_node.
      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>
      4eef678d
    • Steve Longerbeam's avatar
      media: staging/imx: remove devname string from imx_media_subdev · 4dadf056
      Steve Longerbeam authored
      A separate string for the device name, for DEVNAME async match, was
      never needed. Just assign the asd device name to the passed platform
      device name pointer in imx_media_add_async_subdev().
      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>
      4dadf056
    • Steve Longerbeam's avatar
      media: staging/imx: of: allow for recursing downstream · f5abe1c5
      Steve Longerbeam authored
      Calling of_parse_subdev() recursively to a downstream path that has
      already been followed is ok, it just means that call will return
      immediately since the subdevice was already added to the async list.
      
      With that there is no need to determine whether a subdevice's port
      is a sink or source, so 'num_{sink|src}_pads' is no longer used and
      is removed.
      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>
      f5abe1c5
    • Steve Longerbeam's avatar
      media: staging/imx: remove static media link arrays · 621b08ea
      Steve Longerbeam authored
      Remove the static list of media links that were formed at probe time.
      These links can instead be created after all registered async subdevices
      have been bound in imx_media_probe_complete().
      
      The media links between subdevices that exist in the device tree, can
      be created post-async completion by using v4l2_fwnode_parse_link() for
      each endpoint node of that subdevice. Note this approach assumes
      device-tree ports are equivalent to media pads (pad index equals
      port id), and that device-tree endpoints are equivalent to media
      links between pads.
      
      Because links are no longer parsed by imx_media_of_parse(), its sole
      function is now only to add subdevices that it encounters by walking
      the OF graph to the async list, so the function has been renamed
      imx_media_add_of_subdevs().
      
      Similarly, the media links between the IPU-internal subdevice pads (the
      CSI source pads, and all pads between the vdic, ic-prp, ic-prpenc, and
      ic-prpvf subdevices), can be created post-async completion by looping
      through the subdevice's media pads and using the const internal_subdev
      table.
      
      Because links are no longer parsed by imx_media_add_internal_subdevs(),
      this function no longer needs an array of CSI subdevs to form links
      from.
      
      In summary, the following functions, which were used to form a list
      of media links at probe time, are removed:
      
      imx_media_add_pad_link()
      add_internal_links()
      of_add_pad_link()
      
      replaced by these functions, called at probe time, which only populate
      the async subdev list:
      
      imx_media_add_of_subdevs()
      imx_media_add_internal_subdevs()
      
      and these functions, called at async completion, which create the
      media links:
      
      imx_media_create_of_links()
      imx_media_create_csi_of_links()
      imx_media_create_internal_links()
      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>
      621b08ea
    • 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
  3. 14 Dec, 2017 4 commits