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 1 次提交
    • A
      OMAPFB: remove manager->device references · 4249e61e
      Archit Taneja 提交于
      With the introduction of output entities, managers will now connect to outputs.
      Use the helper op for overlays named get_device. This will abstract away the
      information on how to get the device from an overlay.
      
      Using the helper function will reduce the number of pointer dereferences a user
      of OMAPDSS needs to do and reduce risk of a NULL dereference.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      4249e61e
  4. 13 9月, 2012 1 次提交
    • T
      ARM: OMAP2+: Prepare for irqs.h removal · 7d7e1eba
      Tony Lindgren 提交于
      As the interrupts should only be defined in the platform_data, and
      eventually coming from device tree, there's no need to define them
      in header files.
      
      Let's remove the hardcoded references to irqs.h and fix up the includes
      so we don't rely on headers included in irqs.h. Note that we're
      defining OMAP_INTC_START as 0 to the interrupts. This will be needed
      when we enable SPARSE_IRQ. For some drivers we need to add
      #include <plat/cpu.h> for now until these drivers are fixed to
      remove cpu_is_omapxxxx() usage.
      
      While at it, sort som of the includes the standard way, and add
      the trailing commas where they are missing in the related data
      structures.
      
      Note that for drivers/staging/tidspbridge we just define things
      locally.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7d7e1eba
  5. 11 9月, 2012 1 次提交
  6. 08 9月, 2012 1 次提交
    • T
      OMAPFB: clear framebuffers with CPU · ca444158
      Tomi Valkeinen 提交于
      Currently vram.c clears the allocated memory automatically using OMAP
      system DMA. In an effort to reduce OMAP dependencies, we'll do the
      memory clear with CPU from now on.
      
      This patch implements clearing of the framebuffer in omapfb, using
      cfb_fillrect() to do the actual clear.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ca444158
  7. 23 8月, 2012 1 次提交
  8. 10 8月, 2012 1 次提交
  9. 29 6月, 2012 2 次提交
    • A
      OMAPFB: Map interlace field in omap_video_timings with fb vmode flags · 23bae3ad
      Archit Taneja 提交于
      Use the interlace field in omap_video_timings to configure/retrieve
      corresponding fb mode flags in fb_var_screeninfo and fb_videomode.
      
      The interlace field maps with the fb mode flags FB_VMODE_INTERLACED and
      FB_VMODE_NONINTERLACED.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      23bae3ad
    • A
      OMAPFB: Map the newly added omap_video_timings fields with fb sync flags · 783babf3
      Archit Taneja 提交于
      Use the newly added fields in omap_video_timings(hsync, vsync and data_enable
      logic levels and data, hsync and vsync latching related info) to
      configure/retrieve corresponding sync flags in fb_var_screeninfo and
      fb_videomode.
      
      Out of the new fields, hsync_level and vsync_level can be mapped to the fb sync
      flags FB_SYNC_HOR_HIGH_ACT and FB_SYNC_VERT_HIGH_ACT.
      
      When converting fb mode to omap_video_timings, the fields which don't have an
      equivalent parameter in fb are kept as the original values if the panel driver
      has a get_timings op, else they are set to default values.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      783babf3
  10. 22 5月, 2012 1 次提交
    • T
      OMAPFB: remove compiler warnings when CONFIG_BUG=n · 4a75cb85
      Tomi Valkeinen 提交于
      If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
      places in code expect the execution to stop, and this causes compiler
      warnings about uninitialized variables and returning from a non-void
      function without a return value.
      
      This patch fixes the warnings by initializing the variables and
      returning properly after BUG() lines. However, the behaviour is still
      undefined after the BUG, but this is the choice the user makes when
      using CONFIG_BUG=n.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      4a75cb85
  11. 11 5月, 2012 2 次提交
  12. 23 2月, 2012 3 次提交
  13. 13 1月, 2012 1 次提交
  14. 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
  15. 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
  16. 14 9月, 2011 1 次提交
  17. 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
  18. 13 5月, 2011 2 次提交
  19. 11 5月, 2011 4 次提交
  20. 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
  21. 10 1月, 2011 1 次提交
  22. 23 10月, 2010 2 次提交
  23. 05 8月, 2010 5 次提交