Skip to content

L
linux-davinci
Switch branch/tag
  1. 20 Aug, 2009 1 commit
    • Pablo Bitton's avatar
      Add support for SPI in DaVinci DM6446 (and try to keep support for · 96836edc
      Pablo Bitton authored 
      DM355/DM365/DM6467 and DA8xx).  Mostly the same as the patch by Sandeep
Paulraj.

This has been tested on the DM6446 by defining a spidev device and using a
scope (to check correctness) and a hardware loopback.

This was NOT tested on DM355, DM365 and DM6467 - in fact, it will probably
not work "as is" because its default mode is CS low-inactive (default mode
of SPI in kernel) - need to set CS_HIGH mode to work as in the previous
patch.

Changes from the patch by Sandeep Paulraj:

Bug fixes:
 * Additional word written with chip select up after each transfer.
   Particulary problematic with NO_CS mode where this word can't be
   distiguished from correct words. Problem was in davinci_chip_select.
 * setup() for one chip select may interfere with transfer for another
 * Small nitpicks (bits that can be changed only on VERSION_2)

Features added:
 * Support DM6446
 * Support CS_HIGH mode (using SPIDEF register). Note that CS low is default.

Other:
 * Less accesses to registers used.
 * Once-per-device configuration is done only in probe(), not each transfer.

Uglyness still there:
 * VERSION_X definitions for different SPI controllers - added VERSION_3
   for the dm6446, which is ugly.

NOTE:
This patch is based on following patches:

SPI: DaVinci: Adding SPI driver for DM3xx/DM6467/DA8xx

 The patch adds support for SPI in DaVinci
 DM355/DM365/DM6467 and DA8xx.

 This has been tested on the DM355, DM365 and DM6467 EVMs using
 the EEPROM connected to SPI0
Signed-off-by: default avatarSandeep Paulraj <s-paulraj@ti.com>

DaVinci: DM646x: Adding Support for SPI

 The patch does the following

 1) Adds a clock for SPI
 2) Defines resources specific to DM646x SOC
Signed-off-by: default avatarSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: default avatarPablo Bitton <pablo.bitton@gmail.com>
Cc: Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      96836edc
  3. 14 Aug, 2009 5 commits
  5. 31 Jul, 2009 1 commit
  7. 10 Aug, 2009 1 commit
  9. 31 Jul, 2009 5 commits
  11. 24 Jun, 2009 1 commit
  13. 23 Jul, 2009 1 commit
  15. 18 Jul, 2009 3 commits
  17. 24 Jun, 2009 1 commit
  19. 25 Jul, 2009 1 commit
  21. 18 Jul, 2009 1 commit
  23. 20 Aug, 2009 2 commits
  25. 17 Aug, 2009 1 commit
    • Andrew Morton's avatar
      ERROR: "foo * bar" should be "foo *bar" · aa43fdfe
      Andrew Morton authored 
      #357: FILE: fs/proc/kcore.c:486:
+static int open_kcore(struct inode * inode, struct file *filp)

total: 1 errors, 0 warnings, 309 lines checked

./patches/kcore-use-registerd-physmem-information.patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      aa43fdfe
  27. 21 Aug, 2009 1 commit
    • Andrew Morton's avatar
      fs/proc/kcore.c: In function 'kcore_update_ram': · efb89699
      Andrew Morton authored 
      fs/proc/kcore.c:144: error: 'max_low_pfn' undeclared (first use in this function)
fs/proc/kcore.c:144: error: (Each undeclared identifier is reported only once
fs/proc/kcore.c:144: error: for each function it appears in.)

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      efb89699
  29. 17 Aug, 2009 6 commits
  31. 01 Aug, 2009 1 commit
  33. 16 Jul, 2009 2 commits
    • Stefani Seibold's avatar
      Changes since last posting: · 509dd6a6
      Stefani Seibold authored 
       - fix compatibility with tools/perf/builtin-record.c in upstream kernel

The patch is against 2.6.30 and is tested on intel and ppc architectures.

ChangeLog:
 20. Jan 2009 V0.1
  - First Version for Kernel 2.6.28.1
 31. Mar 2009 V0.2
  - Ported to Kernel 2.6.29
 03. Jun 2009 V0.3
  - Ported to Kernel 2.6.30
  - Redesigned what was suggested by Ingo Molnar
  - the thread watch monitor is gone
  - the /proc/stackmon entry is also gone
  - slim down
 04. Jun 2009 V0.4
  - Redesigned everything that was suggested by Andrew Morton
  - slim down
 04. Jun 2009 V0.5
  - Code cleanup
 06. Jun 2009 V0.6
  - Fix missing mm->mmap_sem locking in function task_show_stack_usage()
  - Code cleanup
 10. Jun 2009 V0.7
  - update Documentation/filesystem/proc.txt
 10. Jun 2009 V0.8
  - change maps/smaps output, displays now the max. stack size
 24. Jun 2009 V0.9
  - use walk_page_range() to determinate the stack usage high water mark
  - include swapped pages to the stack usage high water mark count
 24. Jun 2009 V0.10
  - fix off by one bug
  - cleanup

 fs/exec.c                          |    2
 include/linux/sched.h              |    1
 kernel/fork.c                      |    2
Signed-off-by: default avatarStefani Seibold <stefani@seibold.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      509dd6a6
    • Stefani Seibold's avatar
      A patch to give a better overview of the userland application stack usage, · 76ad5485
      Stefani Seibold authored 
      especially for embedded linux.

Currently you are only able to dump the main process/thread stack usage
which is showed in /proc/pid/status by the "VmStk" Value.  But you get no
information about the consumed stack memory of the the threads.

There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which marks
the vm mapping where the thread stack pointer reside with "[thread stack
xxxxxxxx]".  xxxxxxxx is the maximum size of stack.  This is a value
information, because libpthread doesn't set the start of the stack to the
top of the mapped area, depending of the pthread usage.

A sample output of /proc/<pid>/task/<tid>/maps looks like:

08048000-08049000 r-xp 00000000 03:00 8312       /opt/z
08049000-0804a000 rw-p 00001000 03:00 8312       /opt/z
0804a000-0806b000 rw-p 00000000 00:00 0          [heap]
a7d12000-a7d13000 ---p 00000000 00:00 0
a7d13000-a7f13000 rw-p 00000000 00:00 0          [thread stack: 001ff4b4]
a7f13000-a7f14000 ---p 00000000 00:00 0
a7f14000-a7f36000 rw-p 00000000 00:00 0
a7f36000-a8069000 r-xp 00000000 03:00 4222       /lib/libc.so.6
a8069000-a806b000 r--p 00133000 03:00 4222       /lib/libc.so.6
a806b000-a806c000 rw-p 00135000 03:00 4222       /lib/libc.so.6
a806c000-a806f000 rw-p 00000000 00:00 0
a806f000-a8083000 r-xp 00000000 03:00 14462      /lib/libpthread.so.0
a8083000-a8084000 r--p 00013000 03:00 14462      /lib/libpthread.so.0
a8084000-a8085000 rw-p 00014000 03:00 14462      /lib/libpthread.so.0
a8085000-a8088000 rw-p 00000000 00:00 0
a8088000-a80a4000 r-xp 00000000 03:00 8317       /lib/ld-linux.so.2
a80a4000-a80a5000 r--p 0001b000 03:00 8317       /lib/ld-linux.so.2
a80a5000-a80a6000 rw-p 0001c000 03:00 8317       /lib/ld-linux.so.2
afaf5000-afb0a000 rw-p 00000000 00:00 0          [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]


Also there is a new entry "stack usage" in /proc/<pid>/{task/*,}/status
which will you give the current stack usage in kb.

A sample output of /proc/self/status looks like:

Name:	cat
State:	R (running)
Tgid:	507
Pid:	507
.
.
.
CapBnd:	fffffffffffffeff
voluntary_ctxt_switches:	0
nonvoluntary_ctxt_switches:	0
Stack usage:	12 kB

I also fixed stack base address in /proc/<pid>/{task/*,}/stat to the base
address of the associated thread stack and not the one of the main
process.  This makes more sense.
Signed-off-by: default avatarStefani Seibold <stefani@seibold.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      76ad5485
  35. 15 Aug, 2009 1 commit
  37. 14 Aug, 2009 1 commit
  39. 01 Jul, 2009 1 commit
  41. 23 Jul, 2009 1 commit
    • Oleg Nesterov's avatar
      The exiting sub-thread flushes /proc/pid only, but this doesn't buy too · 878ff729
      Oleg Nesterov authored 
      much: ps and friends mostly use /proc/tid/task/pid.

Remove "if (thread_group_leader())" checks from proc_flush_task() path,
this means we always remove /proc/tid/task/pid dentry on exit, and this
actually matches the comment above proc_flush_task().

The test-case:

	static void* tfunc(void *arg)
	{
		char name[256];

		sprintf(name, "/proc/%d/task/%ld/status", getpid(), gettid());
		close(open(name, O_RDONLY));

		return NULL;
	}

	int main(void)
	{
		pthread_t t;

		for (;;) {
			if (!pthread_create(&t, NULL, &tfunc, NULL))
				pthread_join(t, NULL);
		}
	}

slabtop shows that pid/proc_inode_cache/etc grow quickly and
"indefinitely" until the task is killed or shrink_slab() is called, not
good.  And the main thread needs a lot of time to exit.

The same can happen if something like "ps -efL" runs continuously, while
some application spawns short-living threads.
Reported-by: default avatar"James M. Leddy" <jleddy@redhat.com>
Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dominic Duval <dduval@redhat.com>
Cc: Frank Hirtz <fhirtz@redhat.com>
Cc: "Fuller, Johnray" <Johnray.Fuller@gs.com>
Cc: Larry Woodman <lwoodman@redhat.com>
Cc: Paul Batkowski <pbatkowski@redhat.com>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      878ff729
  43. 21 Jul, 2009 1 commit
  45. 18 Aug, 2009 1 commit