Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 5月, 2019 1 次提交
  3. 02 5月, 2019 1 次提交
  5. 30 4月, 2019 1 次提交
  7. 26 4月, 2019 11 次提交
  9. 25 4月, 2019 3 次提交
  11. 20 4月, 2019 1 次提交
  13. 19 4月, 2019 1 次提交
  15. 18 4月, 2019 2 次提交
  17. 12 4月, 2019 2 次提交
    • U
      PM / core: Propagate dev->power.wakeup_path when no callbacks · dc351d4c
      由 Ulf Hansson 提交于 
      The dev->power.direct_complete flag may become set in device_prepare() in
case the device don't have any PM callbacks (dev->power.no_pm_callbacks is
set). This leads to a broken behaviour, when there is child having wakeup
enabled and relies on its parent to be used in the wakeup path.

More precisely, when the direct complete path becomes selected for the
child in __device_suspend(), the propagation of the dev->power.wakeup_path
becomes skipped as well.

Let's address this problem, by checking if the device is a part the wakeup
path or has wakeup enabled, then prevent the direct complete path from
being used.
Reported-by: NLoic Pallardy <loic.pallardy@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
[ rjw: Comment cleanup ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      dc351d4c
    • U
      PM / Domains: Add genpd governor for CPUs · e9499968
      由 Ulf Hansson 提交于 
      After some preceding changes, PM domains managed by genpd may contain
CPU devices, so idle state residency values should be taken into
account during the state selection process. [The residency value is
the minimum amount of time to be spent by a CPU (or a group of CPUs)
in an idle state in order to save more energy than could be saved
by picking up a shallower idle state.]

For this purpose, add a new genpd governor, pm_domain_cpu_gov, to be
used for selecting idle states of PM domains with CPU devices attached
either directly or through subdomains.

The new governor computes the minimum expected idle duration for all
online CPUs attached to a PM domain and its subdomains.  Next, it
finds the deepest idle state whose target residency is within the
expected idle duration and selects it as the target idle state of
the domain.

It should be noted that the minimum expected idle duration computation
is based on the closest timer event information stored in the per-CPU
variables cpuidle_devices for all of the CPUs in the domain.  That
needs to be revisited in future, as obviously there are other reasons
why a CPU may be woken up from idle.
Co-developed-by: NLina Iyer <lina.iyer@linaro.org>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
[ rjw: Changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e9499968
  19. 10 4月, 2019 3 次提交
  21. 09 4月, 2019 3 次提交
  23. 05 4月, 2019 7 次提交
    • G
      drivers: base: power: add proper SPDX identifiers on files that did not have them. · 5de363b6
      由 Greg Kroah-Hartman 提交于 
      There were a few files in the driver core power code that did not have
SPDX identifiers on them, so fix that up.  At the same time, remove the
"free form" text that specified the license of the file, as that is
impossible for any tool to properly parse.

Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5de363b6
    • G
      drivers: base: firmware_loader: add proper SPDX identifiers on files that did not have them. · 50f86aed
      由 Greg Kroah-Hartman 提交于 
      There were two files in the firmware_loader code that did not have SPDX
identifiers on them, so fix that up.

Cc: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50f86aed
    • G
      drivers: base: test: add proper SPDX identifier to Makefile · 47bcc18c
      由 Greg Kroah-Hartman 提交于 
      The Makefile in the drivers/base/test/ directory did not have a SPDX
identifier on it, so fix that up.

Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47bcc18c
    • L
      arch_topology: Make cpu_capacity sysfs node as read-only · 5d777b18
      由 Lingutla Chandrasekhar 提交于 
      If user updates any cpu's cpu_capacity, then the new value is going to
be applied to all its online sibling cpus. But this need not to be correct
always, as sibling cpus (in ARM, same micro architecture cpus) would have
different cpu_capacity with different performance characteristics.
So, updating the user supplied cpu_capacity to all cpu siblings
is not correct.

And another problem is, current code assumes that 'all cpus in a cluster
or with same package_id (core_siblings), would have same cpu_capacity'.
But with commit '5bdd2b3f ("arm64: topology: add support to remove
cpu topology sibling masks")', when a cpu hotplugged out, the cpu
information gets cleared in its sibling cpus. So, user supplied
cpu_capacity would be applied to only online sibling cpus at the time.
After that, if any cpu hotplugged in, it would have different cpu_capacity
than its siblings, which breaks the above assumption.

So, instead of mucking around the core sibling mask for user supplied
value, use device-tree to set cpu capacity. And make the cpu_capacity
node as read-only to know the asymmetry between cpus in the system.
While at it, remove cpu_scale_mutex usage, which used for sysfs write
protection.
Tested-by: NDietmar Eggemann <dietmar.eggemann@arm.com>
Tested-by: NQuentin Perret <quentin.perret@arm.com>
Reviewed-by: NQuentin Perret <quentin.perret@arm.com>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NLingutla Chandrasekhar <clingutla@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d777b18
    • K
      node: Add memory-side caching attributes · acc02a10
      由 Keith Busch 提交于 
      System memory may have caches to help improve access speed to frequently
requested address ranges. While the system provided cache is transparent
to the software accessing these memory ranges, applications can optimize
their own access based on cache attributes.

Provide a new API for the kernel to register these memory-side caches
under the memory node that provides it.

The new sysfs representation is modeled from the existing cpu cacheinfo
attributes, as seen from /sys/devices/system/cpu/<cpu>/cache/.  Unlike CPU
cacheinfo though, the node cache level is reported from the view of the
memory. A higher level number is nearer to the CPU, while lower levels
are closer to the last level memory.

The exported attributes are the cache size, the line size, associativity
indexing, and write back policy, and add the attributes for the system
memory caches to sysfs stable documentation.
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NBrice Goglin <Brice.Goglin@inria.fr>
Tested-by: NBrice Goglin <Brice.Goglin@inria.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      acc02a10
    • K
      node: Add heterogenous memory access attributes · e1cf33aa
      由 Keith Busch 提交于 
      Heterogeneous memory systems provide memory nodes with different latency
and bandwidth performance attributes. Provide a new kernel interface
for subsystems to register the attributes under the memory target
node's initiator access class. If the system provides this information,
applications may query these attributes when deciding which node to
request memory.

The following example shows the new sysfs hierarchy for a node exporting
performance attributes:

  # tree -P "read*|write*"/sys/devices/system/node/nodeY/accessZ/initiators/
  /sys/devices/system/node/nodeY/accessZ/initiators/
  |-- read_bandwidth
  |-- read_latency
  |-- write_bandwidth
  `-- write_latency

The bandwidth is exported as MB/s and latency is reported in
nanoseconds. The values are taken from the platform as reported by the
manufacturer.

Memory accesses from an initiator node that is not one of the memory's
access "Z" initiator nodes linked in the same directory may observe
different performance than reported here. When a subsystem makes use
of this interface, initiators of a different access number may not have
the same performance relative to initiators in other access numbers, or
omitted from the any access class' initiators.

Descriptions for memory access initiator performance access attributes
are added to sysfs stable documentation.
Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NBrice Goglin <Brice.Goglin@inria.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1cf33aa
    • K
      node: Link memory nodes to their compute nodes · 08d9dbe7
      由 Keith Busch 提交于 
      Systems may be constructed with various specialized nodes. Some nodes
may provide memory, some provide compute devices that access and use
that memory, and others may provide both. Nodes that provide memory are
referred to as memory targets, and nodes that can initiate memory access
are referred to as memory initiators.

Memory targets will often have varying access characteristics from
different initiators, and platforms may have ways to express those
relationships. In preparation for these systems, provide interfaces for
the kernel to export the memory relationship among different nodes memory
targets and their initiators with symlinks to each other.

If a system provides access locality for each initiator-target pair, nodes
may be grouped into ranked access classes relative to other nodes. The
new interface allows a subsystem to register relationships of varying
classes if available and desired to be exported.

A memory initiator may have multiple memory targets in the same access
class. The target memory's initiators in a given class indicate the
nodes access characteristics share the same performance relative to other
linked initiator nodes. Each target within an initiator's access class,
though, do not necessarily perform the same as each other.

A memory target node may have multiple memory initiators. All linked
initiators in a target's class have the same access characteristics to
that target.

The following example show the nodes' new sysfs hierarchy for a memory
target node 'Y' with access class 0 from initiator node 'X':

  # symlinks -v /sys/devices/system/node/nodeX/access0/
  relative: /sys/devices/system/node/nodeX/access0/targets/nodeY -> ../../nodeY

  # symlinks -v /sys/devices/system/node/nodeY/access0/
  relative: /sys/devices/system/node/nodeY/access0/initiators/nodeX -> ../../nodeX

The new attributes are added to the sysfs stable documentation.
Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NBrice Goglin <Brice.Goglin@inria.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08d9dbe7
  25. 03 4月, 2019 1 次提交
    • H
      regmap: verify if register is writeable before writing operations · 8b9f9d4d
      由 Han Nandor 提交于 
      regmap provides a couple of ways to validate the register range used.
a) maxim allowed register, b) writable/readable register tables,
c) callback function that can be provided by the driver to validate
a register. regmap framework should verify if registers
are writeable before every write operation. However this doesn't
seems to happen in every situation.

The method `_regmap_raw_write_impl` is only using the `writeable_reg`
callback to verify if register is writeable, ignoring the other two.
This can lead to undefined behaviour since this allows to write to
registers that could be declared un-writeable by using any other
option.

Change `_regmap_raw_write_impl` to use the `regmap_writeable` method
to verify if registers are writable before the write operation.
Signed-off-by: NNandor Han <nandor.han@vaisala.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      8b9f9d4d
  27. 02 4月, 2019 1 次提交
    • S
      PM / wakeup: Use pm_pr_dbg() instead of pr_debug() · 74a1dd86
      由 Stephen Boyd 提交于 
      These prints are useful if we're doing PM suspend debugging. Having them
at pr_debug() level means that we need to either enable DEBUG in this
file, or compile the kernel with dynamic debug capabilities. Both of
these options have drawbacks like custom compilation or opting into all
debug statements being included into the kernel image. Given that we
already have infrastructure to collect PM debugging information with
CONFIG_PM_DEBUG and friends, let's change the pr_debug usage here to be
pm_pr_dbg() instead so we can collect the wakeup information in the
kernel logs.
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      74a1dd86
  29. 01 4月, 2019 2 次提交