1. 02 7月, 2016 3 次提交
    • S
      drm/vmwgfx: Add an option to change assumed FB bpp · 04319d89
      Sinclair Yeh 提交于
      Offer an option for advanced users who want larger modes at 16bpp.
      
      This becomes necessary after the fix: "Work around mode set
      failure in 2D VMs."  Without this patch, there would be no way
      for existing advanced users to get to a high res mode, and the
      regression is they will likely get a black screen after a software
      update on their current VM.
      Signed-off-by: NSinclair Yeh <syeh@vmware.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Cc: <stable@vger.kernel.org>
      04319d89
    • S
      drm/vmwgfx: Work around mode set failure in 2D VMs · 7c20d213
      Sinclair Yeh 提交于
      In a low-memory 2D VM, fbdev can take up a large percentage of
      available memory, making them unavailable for other DRM clients.
      
      Since we do not take fbdev into account when filtering modes,
      we end up claiming to support more modes than we actually do.
      
      As a result, users get a black screen when setting a mode too
      large for current available memory.  In a low-memory VM
      configuration, users can get a black screen for a mode as low
      as 1024x768.
      
      The current mode filtering mechanism keys off of
      SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount
      of surface memory we have.  Since this value is a performance
      suggestion, not a hard limit, and since there should not be much
      of a performance impact for a 2D VM, rather than filtering out
      more modes, we will just allow ourselves to exceed the SVGA's
      performance suggestion.
      
      Also changed assumed bpp to 32 from 16 to make sure we can
      actually support all the modes listed.
      Signed-off-by: NSinclair Yeh <syeh@vmware.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Cc: <stable@vger.kernel.org>
      7c20d213
    • S
      drm/vmwgfx: Add a check to handle host message failure · a9cd9c04
      Sinclair Yeh 提交于
      Discovered by static code analysis tool.  If for some reason communication
      with the host fails more than preset number of retries, return an error
      instead of return garbage.
      Signed-off-by: NSinclair Yeh <syeh@vmware.com>
      Reviewed-by: NCharmaine Lee <charmainel@vmware.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      a9cd9c04
  2. 08 6月, 2016 1 次提交
    • J
      objtool, drm/vmwgfx: Fix "duplicate frame pointer save" warning · 0b0d81e3
      Josh Poimboeuf 提交于
      objtool reports the following warnings:
      
        drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: warning: objtool: vmw_send_msg()+0x107: duplicate frame pointer save
        drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: warning: objtool: vmw_host_get_guestinfo()+0x252: duplicate frame pointer save
      
      To quote Linus:
      
       "The reason is that VMW_PORT_HB_OUT() uses a magic instruction sequence
        (a "rep outsb") to communicate with the hypervisor (it's a virtual GPU
        driver for vmware), and %rbp is part of the communication. So the
        inline asm does a save-and-restore of the frame pointer around the
        instruction sequence.
      
        I actually find the objtool warning to be quite reasonable, so it's
        not exactly a false positive, since in this case it actually does
        point out that the frame pointer won't be reliable over that
        instruction sequence.
      
        But in this particular case it just ends up being the wrong thing -
        the code is what it is, and %rbp just can't have the frame information
        due to annoying magic calling conventions."
      
      Silence the warnings by telling objtool to ignore the two functions
      which use the VMW_PORT_HB_{IN,OUT} macros.
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: DRI <dri-devel@lists.freedesktop.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160526184343.fdtjjjg67smmeekt@trebleSigned-off-by: NIngo Molnar <mingo@kernel.org>
      0b0d81e3
  3. 20 5月, 2016 3 次提交
  4. 05 5月, 2016 3 次提交
  5. 29 4月, 2016 3 次提交
  6. 30 3月, 2016 1 次提交
  7. 16 3月, 2016 1 次提交
  8. 14 3月, 2016 12 次提交
  9. 08 3月, 2016 1 次提交
  10. 05 3月, 2016 1 次提交
  11. 08 2月, 2016 1 次提交
  12. 29 1月, 2016 1 次提交
  13. 28 1月, 2016 1 次提交
  14. 26 1月, 2016 1 次提交
  15. 25 1月, 2016 1 次提交
  16. 14 1月, 2016 2 次提交
  17. 15 12月, 2015 3 次提交
  18. 11 12月, 2015 1 次提交
    • V
      drm: Drop drm_helper_probe_single_connector_modes_nomerge() · 6af3e656
      Ville Syrjälä 提交于
      Now that the mode type bit merge logic is fixed to only merge
      between new probed modes, hopefully we can eliminat the special
      case for qxl and virtio. That is make the merge the mode type
      bits from all matching new probed modes, just like every other
      driver.
      
      qxl and virtio got excluded from the merging in
      commit 3fbd6439 ("drm: copy mode type in drm_mode_connector_list_update()")
      commit abce1ec9 ("Revert "drm: copy mode type in drm_mode_connector_list_update()"")
      commit b87577b7 ("drm: try harder to avoid regression when merging mode bits")
      
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Adam Jackson <ajax@redhat.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: Resolve conflicts with doc updates.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6af3e656