Skip to content
  1. Sep 20, 2010
  2. Sep 19, 2010
    • Al Viro's avatar
      alpha: deal with multiple simultaneously pending signals · 494486a1
      Al Viro authored
      
      
      Unlike the other targets, alpha sets _one_ sigframe and
      buggers off until the next syscall/interrupt, even if
      more signals are pending.  It leads to quite a few unpleasant
      inconsistencies, starting with SIGSEGV potentially arriving
      not where it should and including e.g. mess with sigsuspend();
      consider two pending signals blocked until sigsuspend()
      unblocks them.  We pick the first one; then, if we are hit
      by interrupt while in the handler, we process the second one
      as well.  If we are not, and if no syscalls had been made,
      we get out of the first handler and leave the second signal
      pending; normally sigreturn() would've picked it anyway, but
      here it starts with restoring the original mask and voila -
      the second signal is blocked again.  On everything else we
      get both delivered consistently.
      
      It's actually easy to fix; the only thing to watch out for
      is prevention of double syscall restart.  Fortunately, the
      idea I've nicked from arm fix by rmk works just fine...
      
      Testcase demonstrating the behaviour in question; on alpha
      we get one or both flags set (usually one), on everything
      else both are always set.
      	#include <signal.h>
      	#include <stdio.h>
      	int had1, had2;
      	void f1(int sig) { had1 = 1; }
      	void f2(int sig) { had2 = 1; }
      	main()
      	{
      		sigset_t set1, set2;
      		sigemptyset(&set1);
      		sigemptyset(&set2);
      		sigaddset(&set2, 1);
      		sigaddset(&set2, 2);
      		signal(1, f1);
      		signal(2, f2);
      		sigprocmask(SIG_SETMASK, &set2, NULL);
      		raise(1);
      		raise(2);
      		sigsuspend(&set1);
      		printf("had1:%d had2:%d\n", had1, had2);
      	}
      
      Tested-by: default avatarMichael Cree <mcree@orcon.net.nz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      494486a1
    • Al Viro's avatar
      alpha: fix a 14 years old bug in sigreturn tracing · 53293638
      Al Viro authored
      
      
      The way sigreturn() is implemented on alpha breaks PTRACE_SYSCALL,
      all way back to 1.3.95 when alpha has grown PTRACE_SYSCALL support.
      
      What happens is direct return to ret_from_syscall, in order to bypass
      mangling of a3 (error indicator) and prevent other mutilations of
      registers (e.g. by syscall restart).  That's fine, but... the entire
      TIF_SYSCALL_TRACE codepath is kept separate on alpha and post-syscall
      stopping/notifying the tracer is after the syscall.  And the normal
      path we are forcibly switching to doesn't have it.
      
      So we end up with *one* stop in traced sigreturn() vs. two in other
      syscalls.  And yes, strace is visibly broken by that; try to strace
      the following
      	#include <signal.h>
      	#include <stdio.h>
      	void f(int sig) {}
      	main()
      	{
      		signal(SIGHUP, f);
      		raise(SIGHUP);
      		write(1, "eeeek\n", 6);
      	}
      and watch the show.  The
      	close(1)                                = 405
      in the end of strace output is coming from return value of write() (6 ==
      __NR_close on alpha) and syscall number of exit_group() (__NR_exit_group ==
      405 there).
      
      The fix is fairly simple - the only thing we end up missing is the call
      of syscall_trace() and we can tell whether we'd been called from the
      SYSCALL_TRACE path by checking ra value.  Since we are setting the
      switch_stack up (that's what sys_sigreturn() does), we have the right
      environment for calling syscall_trace() - just before we call
      undo_switch_stack() and return.  Since undo_switch_stack() will overwrite
      s0 anyway, we can use it to store the result of "has it been called from
      SYSCALL_TRACE path?" check.  The same thing applies in rt_sigreturn().
      
      Tested-by: default avatarMichael Cree <mcree@orcon.net.nz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      53293638
    • Al Viro's avatar
      alpha: unb0rk sigsuspend() and rt_sigsuspend() · 392fb6e3
      Al Viro authored
      
      
      Old code used to set regs->r0 and regs->r19 to force the right
      return value.  Leaving that after switch to ERESTARTNOHAND
      was a Bad Idea(tm), since now that screws the restart - if we
      hit the case when get_signal_to_deliver() returns 0, we will
      step back to syscall insn, with v0 set to EINTR and a3 to 1.
      The latter won't matter, since EINTR is 4, aka __NR_write.
      
      Testcase:
      
      	#include <signal.h>
      	#define _GNU_SOURCE
      	#include <unistd.h>
      	#include <sys/syscall.h>
      
      	main()
      	{
      		sigset_t mask;
      		sigemptyset(&mask);
      		sigaddset(&mask, SIGCONT);
      		sigprocmask(SIG_SETMASK, &mask, NULL);
      		kill(0, SIGCONT);
      		syscall(__NR_sigsuspend, 1, "b0rken\n", 7);
      	}
      
      results on alpha in immediate message to stdout...
      
      Fix is obvious; moreover, since we don't need regs anymore, we can
      switch to normal prototypes for these guys and lose the wrappers.
      Even better, rt_sigsuspend() is identical to generic version in
      kernel/signal.c now.
      
      Tested-by: default avatarMichael Cree <mcree@orcon.net.nz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      392fb6e3
    • Al Viro's avatar
      alpha: belated ERESTART_RESTARTBLOCK race fix · 2deba1bd
      Al Viro authored
      
      
      same thing as had been done on other targets back in 2003 -
      move setting ->restart_block.fn into {rt_,}sigreturn().
      
      Tested-by: default avatarMichael Cree <mcree@orcon.net.nz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      2deba1bd
    • Michael Cree's avatar
      alpha: Shift perf event pending work earlier in timer interrupt · bdc8b891
      Michael Cree authored
      
      
      Pending work from the performance event subsystem is executed in
      the timer interrupt.  This patch shifts the call to
      perf_event_do_pending() before the call to update_process_times()
      as the latter may call back into the perf event subsystem and it
      is prudent to have the pending work executed first.
      
      Signed-off-by: default avatarMichael Cree <mcree@orcon.net.nz>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      bdc8b891
    • Mikael Pettersson's avatar
      alpha: wire up fanotify and prlimit64 syscalls · 531f0474
      Mikael Pettersson authored
      
      
      The 2.6.36-rc kernel added three new system calls:
      fanotify_init, fanotify_mark, and prlimit64.  This
      patch wires them up on Alpha.
      
      Built and booted on an XP900.  Untested beyond that.
      
      Signed-off-by: default avatarMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      531f0474
    • Arnd Bergmann's avatar
      alpha: kill big kernel lock · 12e750d9
      Arnd Bergmann authored
      
      
      All uses of the BKL on alpha are totally bogus, nothing
      is really protected by this. Remove the remaining users
      so we don't have to mark alpha as 'depends on BKL'.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: linux-alpha@vger.kernel.org
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      12e750d9
    • Tejun Heo's avatar
      alpha: fix build breakage in asm/cacheflush.h · b97f897d
      Tejun Heo authored
      
      
      Alpha SMP flush_icache_user_range() is implemented as an inline
      function inside include/asm/cacheflush.h.  It dereferences @current
      but doesn't include linux/sched.h and thus causes build failure if
      linux/sched.h wasn't included previously.  Fix it by including the
      needed header file explicitly.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      b97f897d
    • matt mooney's avatar
    • Joe Perches's avatar
  3. Sep 18, 2010
  4. Sep 17, 2010
    • Al Viro's avatar
      arm: fix really nasty sigreturn bug · 653d48b2
      Al Viro authored
      
      
      If a signal hits us outside of a syscall and another gets delivered
      when we are in sigreturn (e.g. because it had been in sa_mask for
      the first one and got sent to us while we'd been in the first handler),
      we have a chance of returning from the second handler to location one
      insn prior to where we ought to return.  If r0 happens to contain -513
      (-ERESTARTNOINTR), sigreturn will get confused into doing restart
      syscall song and dance.
      
      Incredible joy to debug, since it manifests as random, infrequent and
      very hard to reproduce double execution of instructions in userland
      code...
      
      The fix is simple - mark it "don't bother with restarts" in wrapper,
      i.e. set r8 to 0 in sys_sigreturn and sys_rt_sigreturn wrappers,
      suppressing the syscall restart handling on return from these guys.
      They can't legitimately return a restart-worthy error anyway.
      
      Testcase:
      	#include <unistd.h>
      	#include <signal.h>
      	#include <stdlib.h>
      	#include <sys/time.h>
      	#include <errno.h>
      
      	void f(int n)
      	{
      		__asm__ __volatile__(
      			"ldr r0, [%0]\n"
      			"b 1f\n"
      			"b 2f\n"
      			"1:b .\n"
      			"2:\n" : : "r"(&n));
      	}
      
      	void handler1(int sig) { }
      	void handler2(int sig) { raise(1); }
      	void handler3(int sig) { exit(0); }
      
      	main()
      	{
      		struct sigaction s = {.sa_handler = handler2};
      		struct itimerval t1 = { .it_value = {1} };
      		struct itimerval t2 = { .it_value = {2} };
      
      		signal(1, handler1);
      
      		sigemptyset(&s.sa_mask);
      		sigaddset(&s.sa_mask, 1);
      		sigaction(SIGALRM, &s, NULL);
      
      		signal(SIGVTALRM, handler3);
      
      		setitimer(ITIMER_REAL, &t1, NULL);
      		setitimer(ITIMER_VIRTUAL, &t2, NULL);
      
      		f(-513); /* -ERESTARTNOINTR */
      
      		write(1, "buggered\n", 9);
      		return 1;
      	}
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      653d48b2
  5. Sep 15, 2010
  6. Sep 14, 2010
    • Roland McGrath's avatar
      x86-64, compat: Retruncate rax after ia32 syscall entry tracing · eefdca04
      Roland McGrath authored
      
      
      In commit d4d67150, we reopened an old hole for a 64-bit ptracer touching a
      32-bit tracee in system call entry.  A %rax value set via ptrace at the
      entry tracing stop gets used whole as a 32-bit syscall number, while we
      only check the low 32 bits for validity.
      
      Fix it by truncating %rax back to 32 bits after syscall_trace_enter,
      in addition to testing the full 64 bits as has already been added.
      
      Reported-by: default avatarBen Hawkes <hawkes@sota.gen.nz>
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      eefdca04
    • H. Peter Anvin's avatar
      x86-64, compat: Test %rax for the syscall number, not %eax · 36d001c7
      H. Peter Anvin authored
      
      
      On 64 bits, we always, by necessity, jump through the system call
      table via %rax.  For 32-bit system calls, in theory the system call
      number is stored in %eax, and the code was testing %eax for a valid
      system call number.  At one point we loaded the stored value back from
      the stack to enforce zero-extension, but that was removed in checkin
      d4d67150.  An actual 32-bit process
      will not be able to introduce a non-zero-extended number, but it can
      happen via ptrace.
      
      Instead of re-introducing the zero-extension, test what we are
      actually going to use, i.e. %rax.  This only adds a handful of REX
      prefixes to the code.
      
      Reported-by: default avatarBen Hawkes <hawkes@sota.gen.nz>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@kernel.org>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      36d001c7
    • H. Peter Anvin's avatar
      compat: Make compat_alloc_user_space() incorporate the access_ok() · c41d68a5
      H. Peter Anvin authored
      
      
      compat_alloc_user_space() expects the caller to independently call
      access_ok() to verify the returned area.  A missing call could
      introduce problems on some architectures.
      
      This patch incorporates the access_ok() check into
      compat_alloc_user_space() and also adds a sanity check on the length.
      The existing compat_alloc_user_space() implementations are renamed
      arch_compat_alloc_user_space() and are used as part of the
      implementation of the new global function.
      
      This patch assumes NULL will cause __get_user()/__put_user() to either
      fail or access userspace on all architectures.  This should be
      followed by checking the return value of compat_access_user_space()
      for NULL in the callers, at which time the access_ok() in the callers
      can also be removed.
      
      Reported-by: default avatarBen Hawkes <hawkes@sota.gen.nz>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: James Bottomley <jejb@parisc-linux.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: <stable@kernel.org>
      c41d68a5
    • Thomas Gleixner's avatar
      x86: hpet: Work around hardware stupidity · 54ff7e59
      Thomas Gleixner authored
      
      
      This more or less reverts commits 08be9796 (x86: Force HPET
      readback_cmp for all ATI chipsets) and 30a564be (x86, hpet: Restrict
      read back to affected ATI chipsets) to the status of commit 8da854cb
      (x86, hpet: Erratum workaround for read after write of HPET
      comparator).
      
      The delta to commit 8da854cb is mostly comments and the change from
      WARN_ONCE to printk_once as we know the call path of this function
      already.
      
      This needs really in depth explanation:
      
      First of all the HPET design is a complete failure. Having a counter
      compare register which generates an interrupt on matching values
      forces the software to do at least one superfluous readback of the
      counter register.
      
      While it is nice in theory to program "absolute" time events it is
      practically useless because the timer runs at some absurd frequency
      which can never be matched to real world units. So we are forced to
      calculate a relative delta and this forces a readout of the actual
      counter value, adding the delta and programming the compare
      register. When the delta is small enough we run into the danger that
      we program a compare value which is already in the past. Due to the
      compare for equal nature of HPET we need to read back the counter
      value after writing the compare rehgister (btw. this is necessary for
      absolute timeouts as well) to make sure that we did not miss the timer
      event. We try to work around that by setting the minimum delta to a
      value which is larger than the theoretical time which elapses between
      the counter readout and the compare register write, but that's only
      true in theory. A NMI or SMI which hits between the readout and the
      write can easily push us beyond that limit. This would result in
      waiting for the next HPET timer interrupt until the 32bit wraparound
      of the counter happens which takes about 306 seconds.
      
      So we designed the next event function to look like:
      
         match = read_cnt() + delta;
         write_compare_ref(match);
         return read_cnt() < match ? 0 : -ETIME;
      
      At some point we got into trouble with certain ATI chipsets. Even the
      above "safe" procedure failed. The reason was that the write to the
      compare register was delayed probably for performance reasons. The
      theory was that they wanted to avoid the synchronization of the write
      with the HPET clock, which is understandable. So the write does not
      hit the compare register directly instead it goes to some intermediate
      register which is copied to the real compare register in sync with the
      HPET clock. That opens another window for hitting the dreaded "wait
      for a wraparound" problem.
      
      To work around that "optimization" we added a read back of the compare
      register which either enforced the update of the just written value or
      just delayed the readout of the counter enough to avoid the issue. We
      unfortunately never got any affirmative info from ATI/AMD about this.
      
      One thing is sure, that we nuked the performance "optimization" that
      way completely and I'm pretty sure that the result is worse than
      before some HW folks came up with those.
      
      Just for paranoia reasons I added a check whether the read back
      compare register value was the same as the value we wrote right
      before. That paranoia check triggered a couple of years after it was
      added on an Intel ICH9 chipset. Venki added a workaround (commit
      8da854cb) which was reading the compare register twice when the first
      check failed. We considered this to be a penalty in general and
      restricted the readback (thus the wasted CPU cycles) to the known to
      be affected ATI chipsets.
      
      This turned out to be a utterly wrong decision. 2.6.35 testers
      experienced massive problems and finally one of them bisected it down
      to commit 30a564be which spured some further investigation.
      
      Finally we got confirmation that the write to the compare register can
      be delayed by up to two HPET clock cycles which explains the problems
      nicely. All we can do about this is to go back to Venki's initial
      workaround in a slightly modified version.
      
      Just for the record I need to say, that all of this could have been
      avoided if hardware designers and of course the HPET committee would
      have thought about the consequences for a split second. It's out of my
      comprehension why designing a working timer is so hard. There are two
      ways to achieve it:
      
       1) Use a counter wrap around aware compare_reg <= counter_reg
          implementation instead of the easy compare_reg == counter_reg
      
          Downsides:
      
      	- It needs more silicon.
      
      	- It needs a readout of the counter to apply a relative
      	  timeout. This is necessary as the counter does not run in
      	  any useful (and adjustable) frequency and there is no
      	  guarantee that the counter which is used for timer events is
      	  the same which is used for reading the actual time (and
      	  therefor for calculating the delta)
      
          Upsides:
      
      	- None
      
        2) Use a simple down counter for relative timer events
      
          Downsides:
      
      	- Absolute timeouts are not possible, which is not a problem
      	  at all in the context of an OS and the expected
      	  max. latencies/jitter (also see Downsides of #1)
      
         Upsides:
      
      	- It needs less or equal silicon.
      
      	- It works ALWAYS
      
      	- It is way faster than a compare register based solution (One
      	  write versus one write plus at least one and up to four
      	  reads)
      
      I would not be so grumpy about all of this, if I would not have been
      ignored for many years when pointing out these flaws to various
      hardware folks. I really hate timers (at least those which seem to be
      designed by janitors).
      
      Though finally we got a reasonable explanation plus a solution and I
      want to thank all the folks involved in chasing it down and providing
      valuable input to this.
      
      Bisected-by: default avatarNix <nix@esperi.org.uk>
      Reported-by: default avatarArtur Skawina <art.08.09@gmail.com>
      Reported-by: default avatarDamien Wyart <damien.wyart@free.fr>
      Reported-by: default avatarJohn Drescher <drescherjm@gmail.com>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: stable@kernel.org
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      54ff7e59
    • Mark Brown's avatar
      ARM: S3C64XX: Fix dev-spi build · 23a07eb0
      Mark Brown authored
      
      
      The irqs.h usage here got missed in the Samsung platform reorganisation.
      
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: default avatarJassi Brar <jassi.brar@samsung.com>
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      23a07eb0
    • Kukjin Kim's avatar
      ARM: SAMSUNG: Fix on s5p_gpio_[get,set]_drvstr · cbd2780f
      Kukjin Kim authored
      
      
      This patch fixes bug on gpio drive strength helper function.
      
      The offset should be like follwoing.
      -       off = chip->chip.base - pin;
      +       off = pin - chip->chip.base;
      
      In the s5p_gpio_get_drvstr(),
      the second line is unnecessary, because overwrite drvstr.
              drvstr = __raw_readl(reg);
      -       drvstr = 0xffff & (0x3 << shift);
      
      And need 2bit masking before return the drvstr value.
              drvstr = drvstr >> shift;
      +       drvstr &= 0x3;
      
      In the s5p_gpio_set_drvstr(), need relevant bit clear.
              tmp = __raw_readl(reg);
      +       tmp &= ~(0x3 << shift);
              tmp |= drvstr << shift;
      
      Reported-by: default avatarJaecheol Lee <jc.lee@samsung.com>
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      cbd2780f
    • Kukjin Kim's avatar
      ARM: SAMSUNG: Fix on drive strength value · 0770e528
      Kukjin Kim authored
      
      
      This patch fixes on defined drive strength value for GPIO.
      According to data sheet, if we want drive strength 1x, the value
      should be 00(b), if 2x should be 10(b), if 3x should be 01(b),
      and if 4x should be 11(b). Also fixes comment(from S5C to S5P).
      
      Reported-by: default avatarJanghyuck Kim <janghyuck.kim@samsung.com>
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      0770e528
    • Marek Szyprowski's avatar
      ARM: S5PV210: Add FIMC clocks · da01c2f7
      Marek Szyprowski authored
      
      
      These clocks enables FIMC driver to operate on machines, which
      bootloader power gated FIMC devices to save power on boot.
      
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      [kgene.kim@samsung.com: minor title fix]
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      da01c2f7
    • Kyungmin Park's avatar
      ARM: S5PV210: Reduce the iodesc length of systimer · a203a13a
      Kyungmin Park authored
      
      
      It's enough to use 4KiB.
      
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      a203a13a
    • MyungJoo Ham's avatar
      ARM: S5PV210: Update I2C-1 Clock Register Property. · f1c894de
      MyungJoo Ham authored
      
      
      CLK_GATE_IP3[8] is RESERVED. The port "I2C_HDMI_DDC" of CLK_GATE_IP3[10] is
      used as another I2C port. Therefore, defined the unused I2C-1 as another I2C
      there was left undefined but used.
      
      Signed-off-by: default avatarMyungJoo Ham <myungjoo.ham@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      f1c894de
    • Sylwester Nawrocki's avatar
      ARM: S5P: Decrease IO Registers memory region size on FIMC · 80e2f36a
      Sylwester Nawrocki authored
      
      
      IO registers region size of all FIMC versions is less than 1kB so there
      is no need to reserve 1M.
      
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      [kgene.kim@samsung.com: minor title fix]
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      80e2f36a
    • Marek Szyprowski's avatar
      ARM: S5P: Fix DMA coherent mask for FIMC · 0fe7f885
      Marek Szyprowski authored
      
      
      FIMC driver uses DMA_coherent allocator, which requires proper dma mask
      to be set.
      
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      [kgene.kim@samsung.com: minor title fix]
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      0fe7f885
  7. Sep 13, 2010
Loading