Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 22 7月, 2014 1 次提交
  3. 19 7月, 2014 1 次提交
    • D
      Input: add driver for Microchip's CAP1106 · 128bb95d
      由 Daniel Mack 提交于 
      This patch adds a driver for Microchips CAP1106, an I2C driven, 6-channel
capacitive touch sensor.

For now, only the capacitive buttons are supported, and no specific
settings that can be tweaked for individual channels, except for the
device-wide sensitivity gain. The defaults seem to work just fine out of
the box, so I'll leave configurable parameters for someone who's in need
of them and who can actually measure the impact. All registers are
prepared, however. Many of them are just not used for now.

The implementation does not make any attempt to be compatible to platform
data driven boards, but fully depends on CONFIG_OF.

Power management functions are also left for volounteers with the ability
to actually test them.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      128bb95d
  5. 29 5月, 2014 2 次提交
  7. 19 5月, 2014 1 次提交
  9. 15 5月, 2014 3 次提交
  11. 06 5月, 2014 1 次提交
  13. 04 5月, 2014 1 次提交
  15. 29 4月, 2014 1 次提交
    • L
      clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue · 82a56194
      由 Lorenzo Pieralisi 提交于 
      ARM arch timers are tightly coupled with the CPU logic and lose context
on platform implementing HW power management when cores are powered
down at run-time. Marking the arch timers as C3STOP regardless of power
management capabilities causes issues on platforms with no power management,
since in that case the arch timers cannot possibly enter states where the
timer loses context at runtime and therefore can always be used as a high
resolution clockevent device.

In order to fix the C3STOP issue in a way compliant with how real HW
works, this patch adds a boolean property to the arch timer bindings
to define if the arch timer is managed by an always-on power domain.

This power domain is present on all ARM platforms to date, and manages
HW that must not be turned off, whatever the state of other HW
components (eg power controller). On platforms with no power management
capabilities, it is the only power domain present, which encompasses
and manages power supply for all HW components in the system.

If the timer is powered by the always-on power domain, the always-on
property must be present in the bindings which means that the timer cannot
be shutdown at runtime, so it is not a C3STOP clockevent device.
If the timer binding does not contain the always-on property, the timer is
assumed to be power-gateable, hence it must be defined as a C3STOP
clockevent device.

Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Magnus Damm <damm@opensource.se>
Cc: Marc Carino <marc.ceeeee@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      82a56194
  17. 28 4月, 2014 1 次提交
  19. 24 4月, 2014 1 次提交
  21. 23 4月, 2014 1 次提交
  23. 19 4月, 2014 1 次提交
    • T
      Documentation/vm/numa_memory_policy.txt: fix wrong document in numa_memory_policy.txt · 8f28ed92
      由 Tang Chen 提交于 
      In document numa_memory_policy.txt, the following examples for flag
MPOL_F_RELATIVE_NODES are incorrect.

	For example, consider a task that is attached to a cpuset with
	mems 2-5 that sets an Interleave policy over the same set with
	MPOL_F_RELATIVE_NODES.  If the cpuset's mems change to 3-7, the
	interleave now occurs over nodes 3,5-6.  If the cpuset's mems
	then change to 0,2-3,5, then the interleave occurs over nodes
	0,3,5.

According to the comment of the patch adding flag MPOL_F_RELATIVE_NODES,
the nodemasks the user specifies should be considered relative to the
current task's mems_allowed.

 (https://lkml.org/lkml/2008/2/29/428)

And according to numa_memory_policy.txt, if the user's nodemask includes
nodes that are outside the range of the new set of allowed nodes, then
the remap wraps around to the beginning of the nodemask and, if not
already set, sets the node in the mempolicy nodemask.

So in the example, if the user specifies 2-5, for a task whose
mems_allowed is 3-7, the nodemasks should be remapped the third, fourth,
fifth, sixth node in mems_allowed.  like the following:

	mems_allowed:       3  4  5  6  7

	relative index:     0  1  2  3  4
	                    5

So the nodemasks should be remapped to 3,5-7, but not 3,5-6.

And for a task whose mems_allowed is 0,2-3,5, the nodemasks should be
remapped to 0,2-3,5, but not 0,3,5.

	mems_allowed:       0  2  3  5

        relative index:     0  1  2  3
                            4  5
Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Acked-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f28ed92
  25. 18 4月, 2014 2 次提交
  27. 17 4月, 2014 8 次提交
  29. 15 4月, 2014 8 次提交
  31. 14 4月, 2014 1 次提交
  33. 10 4月, 2014 1 次提交
  35. 08 4月, 2014 5 次提交