1. 11 5月, 2012 1 次提交
  2. 23 2月, 2012 3 次提交
  3. 13 1月, 2012 1 次提交
  4. 02 12月, 2011 2 次提交
    • T
      OMAPDSS: APPLY: move ovl->info to apply.c · c1a9febf
      Tomi Valkeinen 提交于
      struct omap_overlayr contains info and info_dirty fields, both of which
      should be internal to apply.c.
      
      This patch moves those fields into ovl_priv data, and names them
      user_info and user_info_dirty.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c1a9febf
    • T
      OMAPDSS: APPLY: rewrite overlay enable/disable · aaa874a9
      Tomi Valkeinen 提交于
      Overlays are currently enabled and disabled with a boolean in the struct
      omap_overlay_info. The overlay info is set with ovl->set_overlay_info(),
      and made into use with mgr->apply().
      
      This doesn't work properly, as the enable/disable status may affect also
      other overlays, for example when using fifo-merge. Thus the enabling and
      disabling of the overlay needs to be done outside the normal overlay
      configuration.
      
      This patch achieves that by doing the following things:
      
      1) Add function pointers to struct omap_overlay: enable(), disable() and
      is_enabled(). These are used to do the obvious. The functions may block.
      
      2) Move the "enabled" field from struct omap_overlay to ovl_priv_data.
      
      3) Add a new route for settings to be applied to the HW, called
      "extra_info". The status of the normal info and extra_info are tracked
      separately.
      
      The point here is to allow the normal info to be changed and
      applied in non-blocking matter, whereas the extra_info can only be
      changed when holding the mutex. This makes it possible to, for example,
      set the overlay enable flag, apply it, and wait until the HW has taken
      the flag into use.
      
      This is not possible if the enable flag would be in the normal info, as
      a new value for the flag could be set at any time from the users of
      omapdss.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      aaa874a9
  5. 30 9月, 2011 3 次提交
    • T
      OMAPDSS: remove vaddr from overlay info · 212b0d50
      Tomi Valkeinen 提交于
      overlay_info struct, used to configure overlays, currently includes both
      physical and virtual addresses for the pixels. The vaddr was added to
      support more exotic configurations where CPU would be used to update a
      display, but it is not currently used and there has been no interest in
      the feature. Using CPU to update a screen is also less interesting now
      that OMAP4 has two LCD outputs.
      
      This patch removes the vaddr field, and modifies the users of omapdss
      accordingly. This makes the use of omapdss a bit simpler, as the user
      doesn't need to think if it needs to give the vaddr.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      212b0d50
    • T
      OMAPFB: find best mode from edid · dc891fab
      Tomi Valkeinen 提交于
      Use the new read_edid() function to get EDID information from the
      display (when available), and use the information to use a suitable mode
      at initialization time.
      
      Hot-plug is not yet supported, so the timings selected at init time will
      stay even if the monitor would be changed.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      dc891fab
    • T
      OMAP: OMAPFB: make omapfb start even when a display is missing a driver · bab59b44
      Tomi Valkeinen 提交于
      Currently omapfb wants that all the display devices have a driver,
      otherwise omapfb refuses to start. There's no real requirement to act
      like that, and this patch will make omapfb give a warning and skip that
      device.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bab59b44
  6. 14 9月, 2011 1 次提交
  7. 01 7月, 2011 2 次提交
    • T
      OMAP: DSS2: OMAPFB: Implement auto-update mode · 27cc213e
      Tomi Valkeinen 提交于
      Implement auto-update mode for manual-update displays. omapfb driver
      uses a delayed work to update the display with a constant rate.
      
      The update mode can be changed via OMAPFB_SET_UPDATE_MODE ioctl, which
      previously called omapdss but is now handled inside omapfb, and a new
      sysfs file, "update_mode".
      
      The update interval is by default 20 times per second, but can be
      changed via "auto_update_freq" module parameter. There is also a new
      module parameter "auto_update", which will make omapfb start manual
      update displays in auto-update mode.
      
      This auto-update mode can be used for testing if the userspace does not
      support manual update displays properly. However, it is a very
      inefficient solution, and should be considered more as a hack for
      testing than something that could be used as a long term solution.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      27cc213e
    • T
      OMAP: DSS2: OMAPFB: Add struct to store per-display data · 065a40bd
      Tomi Valkeinen 提交于
      Create a new struct omapfb_display_data to contain omapfb's private
      per-display data. Move the bpp override there.
      
      This struct will be used to hold auto/manual update state of a display
      in the following patches.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      065a40bd
  8. 13 5月, 2011 2 次提交
  9. 11 5月, 2011 4 次提交
  10. 11 3月, 2011 1 次提交
    • J
      OMAPFB: Adding a check for timings in set_def_mode · 371e2081
      Janorkar, Mayuresh 提交于
      When omapfb.mode is passed through bootargs, when omapfb is setting mode,
      it would check if timings passed are fine for panel attached to it.
      It makes use of check_timing API provided by the panel.
      
      In current code if check_timing API is not available for attached panel,
      OMAPFB would return -EINVAL and BPP sent via bootargs will not have any effect.
      
      In case of panels like TAAL panel, omapfb or any other driver should not be allowed to
      change the timings. So bpps sent via bootargs will not have an effect.
      
      In such case we can check only the x_res and y_res with the panels resolution
      and if they match go ahead and set the bpps.
      The bpp value sent via bootarg would have an effect.
      Signed-off-by: NMayuresh Janorkar <mayur@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      371e2081
  11. 10 1月, 2011 1 次提交
  12. 23 10月, 2010 2 次提交
  13. 05 8月, 2010 5 次提交
  14. 03 8月, 2010 6 次提交
  15. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  16. 01 3月, 2010 1 次提交
  17. 24 2月, 2010 4 次提交