1. 17 10月, 2012 1 次提交
  2. 09 10月, 2012 1 次提交
    • K
      mm: kill vma flag VM_RESERVED and mm->reserved_vm counter · 314e51b9
      Konstantin Khlebnikov 提交于
      A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
      currently it lost original meaning but still has some effects:
      
       | effect                 | alternative flags
      -+------------------------+---------------------------------------------
      1| account as reserved_vm | VM_IO
      2| skip in core dump      | VM_IO, VM_DONTDUMP
      3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      
      This patch removes reserved_vm counter from mm_struct.  Seems like nobody
      cares about it, it does not exported into userspace directly, it only
      reduces total_vm showed in proc.
      
      Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.
      
      remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
      remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.
      
      [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      314e51b9
  3. 26 9月, 2012 3 次提交
  4. 16 8月, 2012 1 次提交
  5. 24 1月, 2012 1 次提交
  6. 16 1月, 2012 1 次提交
  7. 13 1月, 2012 1 次提交
  8. 11 12月, 2011 1 次提交
  9. 07 12月, 2011 1 次提交
  10. 02 12月, 2011 1 次提交
    • 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
  11. 07 11月, 2011 4 次提交
  12. 04 11月, 2011 1 次提交
  13. 03 10月, 2011 1 次提交
    • A
      OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting · 11354dd5
      Archit Taneja 提交于
      On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
      to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
      OMAP4, alpha blending is always enabled by default, if the above bits are set,
      we switch to an OMAP3 compatibility mode where the zorder values in the pipeline
      attribute registers are ignored and a fixed priority is configured.
      
      Rename the manager_info member "alpha_enabled" to "partial_alpha_enabled" for
      more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
      FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and OMAP4
      alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2 user is
      expected to check for the ZORDER cap, if an overlay doesn't have this cap, the
      user is expected to set the parameter partial_alpha_enabled. If the overlay has
      ZORDER cap, the DSS2 user can assume that alpha blending is already enabled.
      
      Don't support OMAP3 compatibility mode for now. Trying to read/write to
      alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does not
      set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.
      
      Change alpha_enabled to partial_alpha_enabled in the omap_vout driver. Use
      overlay cap "OMAP_DSS_OVL_CAP_GLOBAL_ALPHA" to check if overlay supports alpha
      blending or not. Replace this with checks for VIDEO1 pipeline.
      
      Cc: linux-media@vger.kernel.org
      Cc: Lajos Molnar <molnar@ti.com>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      11354dd5
  14. 30 9月, 2011 1 次提交
    • 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
  15. 22 9月, 2011 1 次提交
  16. 28 7月, 2011 8 次提交
  17. 11 7月, 2011 1 次提交
  18. 02 7月, 2011 2 次提交
  19. 11 5月, 2011 1 次提交
  20. 31 3月, 2011 1 次提交
  21. 29 12月, 2010 1 次提交
  22. 02 11月, 2010 1 次提交
  23. 21 10月, 2010 1 次提交
  24. 03 8月, 2010 1 次提交
  25. 09 7月, 2010 2 次提交
  26. 01 6月, 2010 1 次提交