Skip to content
Snippets Groups Projects
  1. Mar 16, 2023
  2. Jun 19, 2019
  3. Apr 01, 2019
  4. Dec 29, 2015
    • Tomi Valkeinen's avatar
      omapfb: copy omapdss & displays for omapfb · f76ee892
      Tomi Valkeinen authored
      
      This patch makes a copy of the omapdss driver and the omap panel &
      encoder drivers for omapfb. The purpose is to separate omapdrm and
      omapfb drivers from each other.
      
      Note that this patch only does a direct copy of the files without any
      other modifications. The files are not yet used.
      
      The original files are in:
      
      drivers/video/fbdev/omap2/dss/
      drivers/video/fbdev/omap2/displays-new/
      
      Here's a more detailed explanation about this and the following patches,
      from the introduction mail of the patch series:
      
      A short background on the current status. We have the following
      entities:
      
      * omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
        display subsystem IPs used on OMAP (and related) SoCs. It offers only a
        kernel internal API, and does not implement anything for fbdev or drm.
      
      * omapdss panels and encoders, located in
        drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
        drivers, which use APIs offered by omapdss driver. These also don't implement
        anything for fbdev or drm.
      
      * omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
        uses omapdss and the panel/encoder drivers to operate the hardware.
      
      * omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
        driver, which uses omapdss and the panel/encoder drivers to operate the
        hardware.
      
      * omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
        which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
      
      So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
      those use the same low level drivers. Without going to the historical details
      why the architecture is like that, I think it's finally time to change that.
      
      The situation with omapfb+omap_vout is that it still works, but no new features
      have been added for a long time, and I want to keep it working as it's still
      being used.  At some point in the future I'd like to remove omapfb and
      omap_vout altogether.
      
      Omapdrm, on the other hand, is being actively developed. Sharing the low level
      parts with omapfb makes that development more difficult than it should be. It
      also "hides" half of the development, as everything happening in the low level
      parts resides under fbdev directory, not in the drm directory.
      
      I've been wanting to clean this up for a long time, but I haven't figured out a
      very good way to do it. I still haven't, but here's the best way I have come up
      with.
      
      This series makes a full copy of the low level parts, omapdss and panel/encoder
      drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
      copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
      the current files moved. This way git will associate the omapdrm version with
      the old files.
      
      The omapfb+omap_vout versions won't be touched unless there are some big issues
      there.
      
      The omapdrm versions can be refactored and cleaned up, as the omapfb support
      code is no longer needed. We can perhaps also merge omapdss and omapdrm into
      the same kernel module.
      
      This series only does the copy, and the absolutely necessary parts. No further
      cleanups are done yet.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Acked-by: default avatarRob Clark <robdclark@gmail.com>
      f76ee892
    • Julia Lawall's avatar
      video: omapdss: delete unneeded of_node_put · 9dec58e6
      Julia Lawall authored
      Device node iterators perform an of_node_put on each iteration, so putting
      an of_node_put before a continue results in a double put.
      
      A simplified version of the semantic match that finds this problem is as
      follows (http://coccinelle.lip6.fr
      
      ):
      
      // <smpl>
      @@
      expression root,e;
      local idexpression child;
      iterator i;
      @@
      
       i(..., child, ...) {
         ... when != of_node_get(child)
      *  of_node_put(child);
         ...
      *  continue;
      }
      // </smpl>
      
      Signed-off-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      9dec58e6
  5. Feb 23, 2015
  6. Feb 04, 2015
  7. Jun 26, 2014
  8. May 28, 2014
Loading