1. 07 3月, 2014 3 次提交
    • P
      drm/radeon: silence GCC warning on 32 bit · 0d997b68
      Paul Bolle 提交于
      Building radeon_ttm.o on 32 bit x86 triggers a warning:
          In file included from include/asm-generic/bug.h:13:0,
                           from [...]/arch/x86/include/asm/bug.h:38,
                           from include/linux/bug.h:4,
                           from include/drm/drm_mm.h:39,
                           from include/drm/drm_vma_manager.h:26,
                           from include/drm/ttm/ttm_bo_api.h:35,
                           from drivers/gpu/drm/radeon/radeon_ttm.c:32:
          drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_gtt_read':
          include/linux/kernel.h:712:17: warning: comparison of distinct pointer types lacks a cast [enabled by default]
            (void) (&_min1 == &_min2);  \
                           ^
          drivers/gpu/drm/radeon/radeon_ttm.c:938:22: note: in expansion of macro 'min'
             ssize_t cur_size = min(size, PAGE_SIZE - off);
                                ^
      
      Silence this warning by using min_t(). Since cur_size will never be
      negative and its upper bound is PAGE_SIZE, we can change its type to
      size_t and use min_t(size_t, [...]) here.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      0d997b68
    • A
      drm/radeon: resume old pm late · bc6a6295
      Alex Deucher 提交于
      Moving the pm resume up in the init order to fix
      dpm seems to have regressed somes cases with the old
      pm code.  Move it back to late resume.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      bc6a6295
    • L
      drm/radeon: TTM must be init with cpu-visible VRAM, v2 · 14eedc32
      Lauri Kasanen 提交于
      Without this, a bo may get created in the cpu-inaccessible vram.
      Before the CP engines get setup, all copies are done via cpu memcpy.
      
      This means that the cpu tries to read from inaccessible memory, fails,
      and the radeon module proceeds to disable acceleration.
      
      Doing this has no downsides, as the real VRAM size gets set as soon as the
      CP engines get init.
      
      This is a candidate for 3.14 fixes.
      
      v2: Add comment on why the function is used
      Signed-off-by: NLauri Kasanen <cand@gmx.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Cc: stable@vger.kernel.org
      14eedc32
  2. 05 3月, 2014 1 次提交
  3. 04 3月, 2014 3 次提交
  4. 03 3月, 2014 12 次提交
  5. 02 3月, 2014 8 次提交
  6. 01 3月, 2014 10 次提交
  7. 28 2月, 2014 3 次提交
    • S
      arm64: mm: Add double logical invert to pte accessors · 84fe6826
      Steve Capper 提交于
      Page table entries on ARM64 are 64 bits, and some pte functions such as
      pte_dirty return a bitwise-and of a flag with the pte value. If the
      flag to be tested resides in the upper 32 bits of the pte, then we run
      into the danger of the result being dropped if downcast.
      
      For example:
      	gather_stats(page, md, pte_dirty(*pte), 1);
      where pte_dirty(*pte) is downcast to an int.
      
      This patch adds a double logical invert to all the pte_ accessors to
      ensure predictable downcasting.
      Signed-off-by: NSteve Capper <steve.capper@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      84fe6826
    • H
      dm cache: fix truncation bug when mapping I/O to >2TB fast device · e0d849fa
      Heinz Mauelshagen 提交于
      When remapping a block to the cache's fast device that is larger than
      2TB we must not truncate the destination sector to 32bits.  The 32bit
      temporary result of from_cblock() was being overflowed in
      remap_to_cache() due to the logical left shift.
      
      Use an intermediate 64bit type to store the 32bit from_cblock() result
      to fix the overflow.
      Signed-off-by: NHeinz Mauelshagen <heinzm@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org
      e0d849fa
    • J
      perf tools: Fix strict alias issue for find_first_bit · b39c2a57
      Jiri Olsa 提交于
      When compiling perf tool code with gcc 4.4.7 I'm getting
      following error:
      
          CC       util/session.o
        cc1: warnings being treated as errors
        util/session.c: In function ‘perf_session_deliver_event’:
        tools/perf/util/include/linux/bitops.h:109: error: dereferencing pointer ‘p’ does break strict-aliasing rules
        tools/perf/util/include/linux/bitops.h:101: error: dereferencing pointer ‘p’ does break strict-aliasing rules
        util/session.c:697: note: initialized from here
        tools/perf/util/include/linux/bitops.h:101: note: initialized from here
        make[1]: *** [util/session.o] Error 1
        make: *** [util/session.o] Error 2
      
      The aliased types here are u64 and unsigned long pointers, which is safe
      for the find_first_bit processing.
      
      This error shows up for me only for gcc 4.4 on 32bit x86, even for
      -Wstrict-aliasing=3, while newer gcc are quiet and scream here for
      -Wstrict-aliasing={2,1}. Looks like newer gcc changed the rules for
      strict alias warnings.
      
      The gcc documentation offers workaround for valid aliasing by using
      __may_alias__ attribute:
      
        http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Type-Attributes.html
      
      Using this workaround for the find_first_bit function.
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1393434867-20271-1-git-send-email-jolsa@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b39c2a57