Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 7月, 2010 5 次提交
    • R
      ARM: OMAP: Cleanup OMAP FB SDRAM reservation · a1af0fbb
      由 Russell King 提交于 
      The logic in this file is rather convoluted, but essentially:

1. region type 0 is SDRAM
2. referring to the code fragment
                if (set_fbmem_region_type(&rg, OMAPFB_MEMTYPE_SDRAM,
                                          sdram_start, sdram_size) < 0 ||
                    (rg.type != OMAPFB_MEMTYPE_SDRAM))
                        continue;
   - if rg.type is not OMAPFB_MEMTYPE_SDRAM, set_fbmem_region_type()
     returns zero immediately (since rg.type is non-zero), and so we
     'continue'.
   - if rg.type is OMAPFB_MEMTYPE_SDRAM, and rg.paddr is zero,
     we fall through.
   - if rg.type is OMAPFB_MEMTYPE_SDRAM, and the region lies within
     SDRAM, we fall through.
   - if rg.type is OMAPFB_MEMTYPE_SDRAM, and the region is not within
     SDRAM, we 'continue'.
3. check_fbmem_region seems unnecessary.
   - we know rg.type is OMAPFB_MEMTYPE_SDRAM
   - we can check rg.size independently
   - bootmem_reserve() can check for overlapping reservations itself
   - we've already validated that the requested region lies within SDRAM.
4. avoid BUG()ing if the region entry is already set; print an error,
   and mark the configuration invalid - at least we'll continue booting
   so the error message has a chance of being logged/visible via serial
   console.

With these changes in place, it makes the code much easier to understand
and hence easier to convert to LMB.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a1af0fbb
    • R
      ARM: Move platform memory reservations out of generic code · 98c672cf
      由 Russell King 提交于 
      Move the platform specific bootmem memory reservations out of
arch/arm/mm/mmu.c into their respective platform files.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      98c672cf
    • R
      ARM: Remove 'node' argument form arch_adjust_zones() · b65b4781
      由 Russell King 提交于 
      Since we no longer support discontigmem, node is always zero, so
remove this argument.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b65b4781
    • R
      ARM: Remove DISCONTIGMEM support · be370302
      由 Russell King 提交于 
      Everything should now be using sparsemem rather than discontigmem, so
remove the code supporting discontigmem from ARM.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      be370302
    • R
      ARM: Precalculate vmalloc_min · 79612395
      由 Russell King 提交于 
      Rather than storing the minimum size of the vmalloc area, store the
maximum permitted address of the vmalloc area instead.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      79612395
  3. 15 7月, 2010 4 次提交
  5. 14 7月, 2010 3 次提交
  7. 13 7月, 2010 8 次提交
  9. 12 7月, 2010 10 次提交
  11. 10 7月, 2010 3 次提交
    • R
      ARM: lockdep: fix unannotated irqs-on · ac78884e
      由 Russell King 提交于 
      CPU: Testing write buffer coherency: ok
------------[ cut here ]------------
WARNING: at kernel/lockdep.c:3145 check_flags+0xcc/0x1dc()
Modules linked in:
[<c0035120>] (unwind_backtrace+0x0/0xf8) from [<c0355374>] (dump_stack+0x20/0x24)
[<c0355374>] (dump_stack+0x20/0x24) from [<c0060c04>] (warn_slowpath_common+0x58/0x70)
[<c0060c04>] (warn_slowpath_common+0x58/0x70) from [<c0060c3c>] (warn_slowpath_null+0x20/0x24)
[<c0060c3c>] (warn_slowpath_null+0x20/0x24) from [<c008f224>] (check_flags+0xcc/0x1dc)
[<c008f224>] (check_flags+0xcc/0x1dc) from [<c00945dc>] (lock_acquire+0x50/0x140)
[<c00945dc>] (lock_acquire+0x50/0x140) from [<c0358434>] (_raw_spin_lock+0x50/0x88)
[<c0358434>] (_raw_spin_lock+0x50/0x88) from [<c00fd114>] (set_task_comm+0x2c/0x60)
[<c00fd114>] (set_task_comm+0x2c/0x60) from [<c007e184>] (kthreadd+0x30/0x108)
[<c007e184>] (kthreadd+0x30/0x108) from [<c0030104>] (kernel_thread_exit+0x0/0x8)
---[ end trace 1b75b31a2719ed1c ]---
possible reason: unannotated irqs-on.
irq event stamp: 3
hardirqs last  enabled at (2): [<c0059bb0>] finish_task_switch+0x48/0xb0
hardirqs last disabled at (3): [<c002f0b0>] ret_slow_syscall+0xc/0x1c
softirqs last  enabled at (0): [<c005f3e0>] copy_process+0x394/0xe5c
softirqs last disabled at (0): [<(null)>] (null)

Fix this by ensuring that the lockdep interrupt state is manipulated in
the appropriate places.  We essentially treat userspace as an entirely
separate environment which isn't relevant to lockdep (lockdep doesn't
monitor userspace.)  We don't tell lockdep that IRQs will be enabled
in that environment.

Instead, when creating kernel threads (which is a rare event compared
to entering/leaving userspace) we have to update the lockdep state.  Do
this by starting threads with IRQs disabled, and in the kthread helper,
tell lockdep that IRQs are enabled, and enable them.

This provides lockdep with a consistent view of the current IRQ state
in kernel space.

This also revert portions of 0d928b0b
which didn't fix the problem.
Tested-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ac78884e
    • G
      i2c/mips: Fix error return codes from Sibyte i2c bus driver · 102b59c6
      由 Guenter Roeck 提交于 
      Sibyte i2c bus driver returns non-descriptive error values.
Update to return error values as defined in Documentation/i2c/fault-codes.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
      102b59c6
    • J
      i2c: Fix probability check · 827900c5
      由 Jean Delvare 提交于 
      The new unified probing function differs from the original code, and
the preliminary test whether probing is possible must be updated
accordingly.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
      827900c5
  13. 09 7月, 2010 7 次提交
    • J
      hwmon: Fix autoloading of fschmd on recent Fujitsu machines · faabd47f
      由 Jean Delvare 提交于 
      Fujitsu slightly changed the DMI strings in their recent machines,
(for example the D2778) and this breaks the automatic loading of the
needed fschmd driver. Being more tolerant on string comparison fixes
the issue.

This closes bug #15634:
https://bugzilla.kernel.org/show_bug.cgi?id=15634Signed-off-by: NJean Delvare <khali@linux-fr.org>
Tested-by: NSergey Spiridonov <sena@hurd.homeunix.org>
Cc: Hans de Goede <hdegoede@redhat.com>
      faabd47f
    • J
      hwmon: (coretemp) Properly label the sensors · 3f4f09b4
      由 Jean Delvare 提交于 
      Don't assume that CPU entry number and core ID always match. It
worked in the simple cases (single CPU, no HT) but fails on
multi-CPU systems.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NHuaxu Wan <huaxu.wan@intel.com>
Cc: stable@kernel.org
      3f4f09b4
    • J
      hwmon: (coretemp) Skip duplicate CPU entries · d883b9f0
      由 Jean Delvare 提交于 
      On hyper-threaded CPUs, each core appears twice in the CPU list. Skip
the second entry to avoid duplicate sensors.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NHuaxu Wan <huaxu.wan@intel.com>
Cc: stable@kernel.org
      d883b9f0
    • J
      hwmon: (it87) Fix in7 on IT8720F · 436cad2a
      由 Jean Delvare 提交于 
      The IT8720F has no VIN7 pin, so VCCH should always be routed
internally to VIN7 with an internal divider. Curiously, there still
is a configuration bit to control this, which means it can be set
incorrectly. And even more curiously, many boards out there are
improperly configured, even though the IT8720F datasheet claims that
the internal routing of VCCH to VIN7 is the default setting. So we
force the internal routing in this case.

It turns out that all boards with the wrong setting are from Gigabyte,
so I suspect a BIOS bug. But it's easy enough to workaround in the
driver, so let's do it.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Jean-Marc Spaggiari <jean-marc@spaggiari.org>
Cc: stable@kernel.org
      436cad2a
    • A
      hwmon: (k8temp) Fix temperature reporting for ASB1 processor revisions · d535bad9
      由 Andreas Herrmann 提交于 
      Reported temperature for ASB1 CPUs is too high.
Add ASB1 CPU revisions (these are also non-desktop variants) to the
list of CPUs for which the temperature fixup is not required.

Example: (from LENOVO ThinkPad Edge 13, 01972NG, system was idle)

  Current kernel reports

  $ sensors
  k8temp-pci-00c3
  Adapter: PCI adapter
  Core0 Temp:  +74.0 C
  Core0 Temp:  +70.0 C
  Core1 Temp:  +69.0 C
  Core1 Temp:  +70.0 C

  With this patch I have

  $ sensors
  k8temp-pci-00c3
  Adapter: PCI adapter
  Core0 Temp:  +54.0 C
  Core0 Temp:  +51.0 C
  Core1 Temp:  +48.0 C
  Core1 Temp:  +49.0 C

Cc: stable@kernel.org [.32.x .33.x, .34.x]
Cc: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
      d535bad9
    • L
      ARM: 6184/2: ux500: use neutral PRCMU base · d9e38040
      由 Linus Walleij 提交于 
      The MTU wallclock timing fix-up patch was hardwired to the DB8500
causing a regression. This makes it work on the DB5500 as well.
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d9e38040
    • W
      ARM: 6212/1: atomic ops: add memory constraints to inline asm · 398aa668
      由 Will Deacon 提交于 
      Currently, the 32-bit and 64-bit atomic operations on ARM do not
include memory constraints in the inline assembly blocks. In the
case of barrier-less operations [for example, atomic_add], this
means that the compiler may constant fold values which have actually
been modified by a call to an atomic operation.

This issue can be observed in the atomic64_test routine in
<kernel root>/lib/atomic64_test.c:

00000000 <test_atomic64>:
   0:	e1a0c00d 	mov	ip, sp
   4:	e92dd830 	push	{r4, r5, fp, ip, lr, pc}
   8:	e24cb004 	sub	fp, ip, #4
   c:	e24dd008 	sub	sp, sp, #8
  10:	e24b3014 	sub	r3, fp, #20
  14:	e30d000d 	movw	r0, #53261	; 0xd00d
  18:	e3011337 	movw	r1, #4919	; 0x1337
  1c:	e34c0001 	movt	r0, #49153	; 0xc001
  20:	e34a1aa3 	movt	r1, #43683	; 0xaaa3
  24:	e16300f8 	strd	r0, [r3, #-8]!
  28:	e30c0afe 	movw	r0, #51966	; 0xcafe
  2c:	e30b1eef 	movw	r1, #48879	; 0xbeef
  30:	e34d0eaf 	movt	r0, #57007	; 0xdeaf
  34:	e34d1ead 	movt	r1, #57005	; 0xdead
  38:	e1b34f9f 	ldrexd	r4, [r3]
  3c:	e1a34f90 	strexd	r4, r0, [r3]
  40:	e3340000 	teq	r4, #0
  44:	1afffffb 	bne	38 <test_atomic64+0x38>
  48:	e59f0004 	ldr	r0, [pc, #4]	; 54 <test_atomic64+0x54>
  4c:	e3a0101e 	mov	r1, #30
  50:	ebfffffe 	bl	0 <__bug>
  54:	00000000 	.word	0x00000000

The atomic64_set (0x38-0x44) writes to the atomic64_t, but the
compiler doesn't see this, assumes the test condition is always
false and generates an unconditional branch to __bug. The rest of the
test is optimised away.

This patch adds suitable memory constraints to the atomic operations on ARM
to ensure that the compiler is informed of the correct data hazards. We have
to use the "Qo" constraints to avoid hitting the GCC anomaly described at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492 , where the compiler
makes assumptions about the writeback in the addressing mode used by the
inline assembly. These constraints forbid the use of auto{inc,dec} addressing
modes, so it doesn't matter if we don't use the operand exactly once.

Cc: stable@kernel.org
Reviewed-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      398aa668