1. 07 7月, 2009 10 次提交
    • I
      drivers/video/s3c-fb.c: fix clock setting for Samsung SoC Framebuffer · 600ce1a0
      InKi Dae 提交于
      Correct the CLKVAL_F field value of VIDEO MAIN CONTROLLER 0 REGITSTER.
      
      Frame Rate is 1 / [ { (VSPW+1) + (VBPD+1) + (LIINEVAL + 1) + (VFPD+1)
      } x {(HSPW+1) + (HBPD +1)
      + (HFPD+1) + (HOZVAL + 1) } x { ( CLKVAL+1 ) / ( Frequency of Clock
      source ) } ] and VCLK = Video Clock Source / (CLKVAL +1).
      
      therefore CLKVAL_F should be "CLKVAL_F = Frequency of Clock source / pixel
      clock * refresh".
      
      for this, I added refresh value in platform data like below.
      
      static struct s3c_fb_pd_win xxx_fb_win0 = {
      	/* this is to ensure we use win0 */
      	.win_mode = {
      		.refresh	= 60,
      		.pixclock	= (66+4+2+480)*(15+5+3+800),
      		.left_margin	= 66,
      		.right_margin	= 2,
      		.upper_margin	= 15,
      		.lower_margin	= 3,
      		.hsync_len	= 4,
      		.vsync_len	= 5,
      		.xres		= 480,
      		.yres		= 800,
      	},
      	.max_bpp	= 32,
      	.default_bpp	= 24,
      };
      
      static struct s3c_fb_platdata xxx_lcd_pdata __initdata = {
      	.win[0]		= &xxx_fb_win0,
      	.vidcon0	= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
      	.vidcon1	= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC
      			| VIDCON1_INV_VCLK | VIDCON1_INV_VDEN,
      	.setup_gpio	= s5pc1xx_fb_gpio_setup_24bpp,
      };
      
      xxx_machine_init()
      {
                         .
                         .
                         .
                     s3c_fb_set_platdata(&xxx_lcd_pdata);
      }
      
      platform data defined in machine code should be setting using
      s3c_fb_set_platdata().
      Signed-off-by: NInKi Dae <inki.dae@samsung.com>
      Cc: Kyungmin Park <kmpark@infradead.org>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      600ce1a0
    • K
      Fix virt_to_phys() warnings · 5bfd7560
      Kevin Cernekee 提交于
      These warnings were observed on MIPS32 using 2.6.31-rc1 and gcc-4.2.0:
      
      mm/page_alloc.c: In function 'alloc_pages_exact':
      mm/page_alloc.c:1986: warning: passing argument 1 of 'virt_to_phys' makes pointer from integer without a cast
      
      drivers/usb/mon/mon_bin.c: In function 'mon_alloc_buff':
      drivers/usb/mon/mon_bin.c:1264: warning: passing argument 1 of 'virt_to_phys' makes pointer from integer without a cast
      
      [akpm@linux-foundation.org: fix kernel/perf_counter.c too]
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5bfd7560
    • J
      mm: mark page accessed before we write_end() · c8236db9
      Josef Bacik 提交于
      In testing a backport of the write_begin/write_end AOPs, a 10% re-read
      regression was noticed when running iozone.  This regression was
      introduced because the old AOPs would always do a mark_page_accessed(page)
      after the commit_write, but when the new AOPs where introduced, the only
      place this was kept was in pagecache_write_end().
      
      This patch does the same thing in the generic case as what is done in
      pagecache_write_end(), which is just to mark the page accessed before we
      do write_end().
      Signed-off-by: NJosef Bacik <jbacik@redhat.com>
      Acked-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c8236db9
    • H
      elf: fix multithreaded program core dumping on arm · a65e7bfc
      Hui Zhu 提交于
      Fix the multithread program core thread message error.
      
      This issue affects arches with neither has CORE_DUMP_USE_REGSET nor
      ELF_CORE_COPY_TASK_REGS, ARM is one of them.
      
      The thread message of core file is generated in elf_dump_thread_status.
      The register values is set by elf_core_copy_task_regs in this function.
      
      If an arch doesn't define ELF_CORE_COPY_TASK_REGS,
      elf_core_copy_task_regs() will do nothing.  Then the core file will not
      have the register message of thread.
      
      So add elf_core_copy_regs to set regiser values if ELF_CORE_COPY_TASK_REGS
      doesn't define.
      
      The following is how to reproduce this issue:
      
      cat 1.c
      #include <stdio.h>
      #include <pthread.h>
      #include <assert.h>
      
      void td1(void * i)
      {
             while (1)
             {
                     printf ("1\n");
                     sleep (1);
             }
      
             return;
      }
      
      void td2(void * i)
      {
             while (1)
             {
                     printf ("2\n");
                     sleep (1);
             }
      
             return;
      }
      
      int
      main(int argc,char *argv[],char *envp[])
      {
             pthread_t       t1,t2;
      
             pthread_create(&t1, NULL, (void*)td1, NULL);
             pthread_create(&t2, NULL, (void*)td2, NULL);
      
             sleep (10);
      
             assert(0);
      
             return (0);
      }
      arm-xxx-gcc -g -lpthread 1.c -o 1
      copy 1.c and 1 to a arm board.
      Goto this board.
      ulimit -c 1800000
      ./1
      # ./1
      1
      2
      1
      ...
      ...
      1
      1: 1.c:37: main: Assertion `0' failed.
      Aborted (core dumped)
      Then you can get a core file.
      gdb 1 core.xxx
      Without the patch:
      (gdb) info threads
       3 process 909  0x00000000 in ?? ()
       2 process 908  0x00000000 in ?? ()
      * 1 process 907  0x4a6e2238 in raise () from /lib/libc.so.6
      You can found that the pc of 909 and 908 is 0x00000000.
      With the patch:
      (gdb) info threads
       3 process 885  0x4a749974 in nanosleep () from /lib/libc.so.6
       2 process 884  0x4a749974 in nanosleep () from /lib/libc.so.6
      * 1 process 883  0x4a6e2238 in raise () from /lib/libc.so.6
      The pc of 885 and 884 is right.
      Signed-off-by: NHui Zhu <teawater@gmail.com>
      Cc: Amerigo Wang <xiyou.wangcong@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a65e7bfc
    • Z
      sys_sync(): fix 16% performance regression in ffsb create_4k test · 3beab0b4
      Zhang, Yanmin 提交于
      I run many ffsb test cases on JBODs (typically 13/12 disks).  Comparing
      with kernel 2.6.30, 2.6.31-rc1 has about 16% regression with
      ffsb_create_4k.  The sub test case creates files continuously for 10
      minitues and every file is 1MB.
      
      Bisect located below patch.
      
      5cee5815 is first bad commit
      commit 5cee5815
      Author: Jan Kara <jack@suse.cz>
      Date:   Mon Apr 27 16:43:51 2009 +0200
      
          vfs: Make sys_sync() use fsync_super() (version 4)
      
          It is unnecessarily fragile to have two places (fsync_super() and do_sync())
          doing data integrity sync of the filesystem. Alter __fsync_super() to
          accommodate needs of both callers and use it. So after this patch
          __fsync_super() is the only place where we gather all the calls needed to
          properly send all data on a filesystem to disk.
      
      As a matter of fact, ffsb calls sys_sync in the end to make sure all data
      is flushed to disks and the flushing is counted into the result.  vmstat
      shows ffsb is blocked when syncing for a long time.  With 2.6.30, ffsb is
      blocked for a short time.
      
      I checked the patch and did experiments to recover the original methods.
      Eventually, the root cause is the patch deletes the calling to
      wakeup_pdflush when syncing, so only ffsb is blocked on disk I/O.
      wakeup_pdflush could ask pdflush to write back pages with ffsb at the
      same time.
      
      [akpm@linux-foundation.org: restore comment too]
      Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Acked-by: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3beab0b4
    • P
      gcov: exclude code operating in userspace from profiling · f386c61f
      Peter Oberparleiter 提交于
      Fix for this issue on x86_64:
      
      rostedt@goodmis.org wrote:
      > On bootup of the latest kernel my init segfaults. Debugging it,
      > I found  that vread_tsc (a vsyscall) increments some strange
      > kernel memory:
      >
      > 0000000000000000 <vread_tsc>:
      >    0:   55                      push   %rbp
      >    1:   48 ff 05 00 00 00 00    incq   0(%rip)
      >                         # 8 <vread_tsc+0x8>
      >                         4: R_X86_64_PC32        .bss+0x3c
      >    8:   48 89 e5                mov    %rsp,%rbp
      >    b:   66 66 90                xchg   %ax,%ax
      >    e:   48 ff 05 00 00 00 00    incq   0(%rip)
      >                         # 15 <vread_tsc+0x15>
      >                         11: R_X86_64_PC32       .bss+0x44
      >   15:   66 66 90                xchg   %ax,%ax
      >   18:   48 ff 05 00 00 00 00    incq   0(%rip)
      >                         # 1f <vread_tsc+0x1f>
      >                         1b: R_X86_64_PC32       .bss+0x4c
      >   1f:   0f 31                   rdtsc
      >
      >
      > Those "incq" is very bad to happen in vsyscall memory, since
      > userspace can not modify it. You need to make something prevent
      > profiling of vsyscall  memory (like I do with ftrace).
      Signed-off-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Reported-by: NSteven Rostedt <rostedt@goodmis.org>
      Tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f386c61f
    • J
      rtc: ds1374, fix lock imbalance · 28df30e6
      Jiri Slaby 提交于
      When i2c_smbus_read_byte_data fails in ds1374_work, we forgot to unlock
      the held lock.  Fix that.
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Scott Wood <scottwood@freescale.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      28df30e6
    • F
      vlynq: fix typo in Kconfig to enable debugging · efc0cfa6
      Florian Fainelli 提交于
      Fix a typo in the VLYNQ bus driver Kconfig which prevented to turn on
      VLYNQ bus debugging.
      Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      efc0cfa6
    • R
      vlynq: correct typo of missing "CONFIG_" prefix in ifdef · 9e2db5c9
      Robert P. J. Day 提交于
      Fix a typo in the vlynq bus driver which was missing the CONFIG_ prefix to
      turn on debugging code.
      Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
      Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9e2db5c9
    • K
      sisfb: fix regression with uninitalized fb_info->mm_lock mutex · cbad1cbb
      Krzysztof Helt 提交于
      Remove redundant call to the sisfb_get_fix() before sis frambuffer is
      registered.
      
      This fixes a problem with uninitialized the fb_info->mm_lock mutex
      introduced by the commit 537a1bf0 " fbdev: add mutex for fb_mmap
      locking"
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Tested-by: NWu Zhangjin <wuzhangjin@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cbad1cbb
  2. 05 7月, 2009 9 次提交
  3. 04 7月, 2009 8 次提交
  4. 03 7月, 2009 13 次提交