- Jul 03, 2019
-
-
This reverts commit 1be01d4a.
-
arm and arm64: Add Function, Function Graph, Irqsoff, Preempt, Sched Tracer Add Prove Locking Add Prove RCU for arm64: Add USB Net RTL8152 Add USB Net Add USB Net AX8817X Remove Mouse PS2 for arm: Add kernel .config support and /proc/config.gz Add ARM Big.Little cpufreq driver Add ARM Big.Little cpuidle driver Add Sensor Vexpress Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
-
arm and arm64: Add Cgroups support Add Energy Model Add CpuFreq governors and make schedutil default Add Uclamp support for tasks and taskgroups for arm: Add Cpuset support Add Scheduler autogroups Add DIE sched domain level Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
-
The ancient workaround to avoid the cost of updating rq clocks in the middle of a migration causes some issues on asymmetric CPU capacity systems where we use task utilization to determine which cpus fit a task. On quiet systems we can inflate task util after a migration which causes misfit to fire and force-migrate the task. This occurs when: (a) a task has util close to the non-overutilized capacity limit of a particular cpu; and (b) the prev_cpu was quiet otherwise, such that rq clock is sufficiently out of date. e.g. _____ cpu0: ________________________| |______________ |<- misfit happens ______ ___ ___ cpu1: ____| |______________|___| |_________| ->| |<- wakeup migration time last rq clock update When the task util is in just the right range for the system, we can end up migrating an unlucky task back and forth many times until we are lucky and the source rq happens to be updated close to the migration time. In order to address this, lets update both rq_clock and cfs_rq where this could be an issue. Change-Id: I7203fb52f884b599d0c3852442d5c62fd6cbff7f Signed-off-by: Chris Redpath <chris.redpath@arm.com>
-
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
-
On updates of task group (TG) clamp values, ensure that these new values are enforced on all RUNNABLE tasks of the task group, i.e. all RUNNABLE tasks are immediately boosted and/or clamped as requested. Do that by slightly refactoring uclamp_bucket_inc(). An additional parameter *cgroup_subsys_state (css) is used to walk the list of tasks in the TGs and update the RUNNABLE ones. Do that by taking the rq lock for each task, the same mechanism used for cpu affinity masks updates. Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tejun Heo <tj@kernel.org> --- Changes in v11: Message-ID: <20190624174607.GQ657710@devbig004.ftw2.facebook.com> - Ensure group limits always clamps group protection
-
When a task specific clamp value is configured via sched_setattr(2), this value is accounted in the corresponding clamp bucket every time the task is {en,de}qeued. However, when cgroups are also in use, the task specific clamp values could be restricted by the task_group (TG) clamp values. Update uclamp_cpu_inc() to aggregate task and TG clamp values. Every time a task is enqueued, it's accounted in the clamp_bucket defining the smaller clamp between the task specific value and its TG effective value. This allows to: 1. ensure cgroup clamps are always used to restrict task specific requests, i.e. boosted only up to the effective granted value or clamped at least to a certain value 2. implement a "nice-like" policy, where tasks are still allowed to request less then what enforced by their current TG This mimics what already happens for a task's CPU affinity mask when the task is also in a cpuset, i.e. cgroup attributes are always used to restrict per-task attributes. Do this by exploiting the concept of "effective" clamp, which is already used by a TG to track parent enforced restrictions. Apply task group clamp restrictions only to tasks belonging to a child group. While, for tasks in the root group or in an autogroup, only system defaults are enforced. Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tejun Heo <tj@kernel.org>
-
The clamp values are not tunable at the level of the root task group. That's for two main reasons: - the root group represents "system resources" which are always entirely available from the cgroup standpoint. - when tuning/restricting "system resources" makes sense, tuning must be done using a system wide API which should also be available when control groups are not. When a system wide restriction is available, cgroups should be aware of its value in order to know exactly how much "system resources" are available for the subgroups. Utilization clamping supports already the concepts of: - system defaults: which define the maximum possible clamp values usable by tasks. - effective clamps: which allows a parent cgroup to constraint (maybe temporarily) its descendants without losing the information related to the values "requested" from them. Exploit these two concepts and bind them together in such a way that, whenever system default are tuned, the new values are propagated to (possibly) restrict or relax the "effective" value of nested cgroups. Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tejun Heo <tj@kernel.org>
-
In order to properly support hierarchical resources control, the cgroup delegation model requires that attribute writes from a child group never fail but still are (potentially) constrained based on parent's assigned resources. This requires to properly propagate and aggregate parent attributes down to its descendants. Let's implement this mechanism by adding a new "effective" clamp value for each task group. The effective clamp value is defined as the smaller value between the clamp value of a group and the effective clamp value of its parent. This is the actual clamp value enforced on tasks in a task group. Since it can be interesting for userspace, e.g. system management software, to know exactly what the currently propagated/enforced configuration is, the effective clamp values are exposed to user-space by means of a new pair of read-only attributes cpu.util.{min,max}.effective. Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tejun Heo <tj@kernel.org> --- Changes in v11: Message-ID: <20190624174607.GQ657710@devbig004.ftw2.facebook.com> - Removed user-space uclamp.{min.max}.effective API - Ensure group limits always clamps group protections
-
The cgroup CPU bandwidth controller allows to assign a specified (maximum) bandwidth to the tasks of a group. However this bandwidth is defined and enforced only on a temporal base, without considering the actual frequency a CPU is running on. Thus, the amount of computation completed by a task within an allocated bandwidth can be very different depending on the actual frequency the CPU is running that task. The amount of computation can be affected also by the specific CPU a task is running on, especially when running on asymmetric capacity systems like Arm's big.LITTLE. With the availability of schedutil, the scheduler is now able to drive frequency selections based on actual task utilization. Moreover, the utilization clamping support provides a mechanism to bias the frequency selection operated by schedutil depending on constraints assigned to the tasks currently RUNNABLE on a CPU. Giving the mechanisms described above, it is now possible to extend the cpu controller to specify the minimum (or maximum) utilization which should be considered for tasks RUNNABLE on a cpu. This makes it possible to better defined the actual computational power assigned to task groups, thus improving the cgroup CPU bandwidth controller which is currently based just on time constraints. Extend the CPU controller with a couple of new attributes uclamp.{min,max} which allow to enforce utilization boosting and capping for all the tasks in a group. Specifically: - uclamp.min: defines the minimum utilization which should be considered i.e. the RUNNABLE tasks of this group will run at least at a minimum frequency which corresponds to the uclamp.min utilization - uclamp.max: defines the maximum utilization which should be considered i.e. the RUNNABLE tasks of this group will run up to a maximum frequency which corresponds to the uclamp.max utilization These attributes: a) are available only for non-root nodes, both on default and legacy hierarchies, while system wide clamps are defined by a generic interface which does not depends on cgroups. This system wide interface enforces constraints on tasks in the root node. b) enforce effective constraints at each level of the hierarchy which are a restriction of the group requests considering its parent's effective constraints. Root group effective constraints are defined by the system wide interface. This mechanism allows each (non-root) level of the hierarchy to: - request whatever clamp values it would like to get - effectively get only up to the maximum amount allowed by its parent c) have higher priority than task-specific clamps, defined via sched_setattr(), thus allowing to control and restrict task requests. Add two new attributes to the cpu controller to collect "requested" clamp values. Allow that at each non-root level of the hierarchy. Validate local consistency by enforcing uclamp.min < uclamp.max. Keep it simple by not caring now about "effective" values computation and propagation along the hierarchy. Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tejun Heo <tj@kernel.org> --- Changes in v11: Message-ID: <20190624175215.GR657710@devbig004.ftw2.facebook.com> - remove checks for cpu_uclamp_{min,max}_write() from root group - remove enforcement for "protection" being smaller then "limits" - rephrase uclamp extension description to avoid explicit mentioning of the bandwidth concept
-
Convert the cgroup-v1 files to ReST format, in order to allow a later addition to the admin-guide. The conversion is actually: - add blank lines and identation in order to identify paragraphs; - fix tables markups; - add some lists markups; - mark literal blocks; - adjust title markups. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Tejun Heo <tj@kernel.org>
-
a5e112e6 ("cgroup: add cgroup_parse_float()") accidentally added cgroup_parse_float() inside CONFIG_SYSFS block. Move it outside so that it doesn't cause failures on !CONFIG_SYSFS builds. Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: a5e112e6 ("cgroup: add cgroup_parse_float()")
-
cgroup already uses floating point for percent[ile] numbers and there are several controllers which want to take them as input. Add a generic parse helper to handle inputs. Update the interface convention documentation about the use of percentage numbers. While at it, also clarify the default time unit. Signed-off-by: Tejun Heo <tj@kernel.org>
-
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
-
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
-
Updated MHUv2 AMBA ID to 0xbb0d1 from 0x4b0d1 as per the latest change in MHUv2 specification and FVP models. JIRA ID: https://jira.arm.com/browse/PLATFORMS-1389 https://jira.arm.com/browse/PLATFORMS-1508 Change-Id: I2ee6e686e848c358e11ced9e023e76122139a015 Signed-off-by: Samarth Parikh <samarth.parikh@arm.com> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
-
ARM has launched a next version of MHU i.e. MHUv2 with its latest subsystems. The major changes that have gone into MHUv2 are, MHUv2 now have two separate physical channels for Secure & Non-Secure communications with two dedicated channels each for send & receive. So, in all MHUv2 have total of 4 physical channels instead of 1 which was shared across all the communications in case of older version of MHU. Also, with MHUv2 the non-secure communication happens over either High priority channel (N=0) or Low priority channel (N=1) which has an offset of 0x0 or 0x20 respectively. For, secure communication it still uses single channel (N=0) which has an offset of 0x0. MHUv2 can support upto 32 (N=31) sub-channels each having a width of 0x20 across secure & non-secure channel. Base offset of any sub-channel N = (N * 0x20). 0x0 0x20 0x40 0x1000 ---------------------....----- | SE | | | | | ---------------------....----- Secure Transmit Channel 0x0 0x20 0x40 0x1000 ---------------------....----- | SE | | | | | ---------------------....----- Secure Receive Channel 0x0 0x20 0x40 0x1000 ---------------------....----- | HP | LP | | | | ---------------------....----- Non-Secure Transmit Channel 0x0 0x20 0x40 0x1000 ---------------------....----- | HP | LP | | | | ---------------------....----- Non-Secure Receive Channel The register offsets have also changed for STAT, SET & CLEAR registers from 0x0, 0x8 & 0x10 in MHUv1 to 0x0, 0xC & 0x8 in MHUv2 respectively. 0x0 0x4 0x8 0xC 0x1F ------------------------....----- | STAT | | | SET | | | ------------------------....----- Transmit Channel 0x0 0x4 0x8 0xC 0x1F ------------------------....----- | STAT | | CLR | | | | ------------------------....----- Receive Channel With MHUv2, the receiver can be put to sleep by the MHU controller in order to save power. So, in order for the receiver to be awake when the sender wants to send data, the sender has to set ACCESS_REQUEST register first in order to wake-up receiver if it was asleep, state of which can be detected using ACCESS_READY register. ACCESS_REQUEST has an offset of 0xF88 & ACCESS_READY has an offset of 0xF8C and are accessible only on any transmit channel. This patch adds necessary changes required to support the older version of MHU & the latest MHUv2 controller. This patch also updates DT binding for ARM MHU as we need a compatible string as arm,mhuv2-doorbell for differentiating MHUv2 DT and also added second register base (tx base) which would be used as the send channel base for non-secure channels. (If the kernel is running in secure mode then the same tx base address can be used as the send channel base register for secure channel too.) JIRA: https://jira.arm.com/browse/PLATFORMS-826 JIRA: https://jira.arm.com/browse/PLATFORMS-1026 JIRA: https://jira.arm.com/browse/PLATFORMS-1508 Change-Id: I62868dc94ea8ae1ec105db1e3edf4e5bbbff5ae1 Signed-off-by: Samarth Parikh <samarth.parikh@arm.com> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
-
It's sometimes useful to identify the mailbox controller with the name as specified in the devicetree via mbox-name property especially in a system with multiple controllers. This patch adds support to read and record the mailbox controller name. Change-Id: I50cf79bf3b68b2f74d38c29337db30e125fa2e87 Cc: Alexey Klimov <alexey.klimov@arm.com> Cc: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
-
We now have the basic infrastructure and binding to support doorbells on ARM MHU controller. This patch adds all the necessary mailbox operations to add support for the doorbells. Maximum of 32 doorbells are supported on each physical channel, however the total number of doorbells is restricted to 20 in order to save memory. It can increased if required in future. Change-Id: I9788b68bdae97c60d5573c97d2057e531b0f3ba8 Cc: Alexey Klimov <alexey.klimov@arm.com> Cc: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
-
In order to support doorbells, we need a bit of reword around data structures that are per-channel. Since the number of doorbells are not fixed though restricted to maximum of 20, the channel assignment and initialization is move to xlate function. This patch also adds the platform data for the existing support of one channel per physical channel. Change-Id: I8d699c7dcca2a6e272a39582b06a29c14a7e3a62 Cc: Alexey Klimov <alexey.klimov@arm.com> Cc: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
-
In preparation to introduce support for doorbells which require the interrupt handlers to be threaded, this patch moves the existing interrupt handler to threaded handler. Also it moves out the registering and freeing of the handlers from the mailbox startup and shutdown methods. This also is required to support doorbells. Change-Id: I8d7d826fa3b169cdccf7673ea94d7edb4af91c88 Cc: Alexey Klimov <alexey.klimov@arm.com> Cc: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
-
This patch just re-orders some of the headers includes and also drop the ones that are unnecessary. Change-Id: Ie8be759344e780b6abb67c4128c152e1408b2bc3 Cc: Alexey Klimov <alexey.klimov@arm.com> Cc: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
-
Accessing the NOR flash memory from the kernel will disrupt CPU sleep/ idles states and CPU hotplugging. We need to disable this DT node by default. Setups that want to access the flash can modify this entry to enable the flash again but also ensuring to disable CPU idle states and CPU hotplug. The platform firmware assumes the flash is always in read mode while Linux kernel driver leaves NOR flash in "read id" mode after initialization. If it gets used actively, it can be in some other state. So far we had not seen this issue as the NOR flash drivers in kernel were not enabled by default. However it was enable in multi_v7 config by Commit 5f068190 ("ARM: multi_v7_defconfig: Enable support for CFI NOR FLASH") So, let's mark the NOR flash disabled so that the platform can boot again. This based on: Commit 980bbff0 ("ARM64: juno: disable NOR flash node by default") Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
-
This commit removes the open-coded CPU-offline notification with new common code. In particular, this change avoids calling scheduler code using RCU from an offline CPU that RCU is ignoring. This is a minimal change. A more intrusive change might invoke the cpu_check_up_prepare() and cpu_set_state_online() functions at CPU-online time, which would allow onlining throw an error if the CPU did not go offline properly. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Russell King <linux@arm.linux.org.uk> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
-
Signed-off-by: John Stultz <john.stultz@linaro.org>
-
Signed-off-by: Chen Feng <puck.chen@hisilicon.com>
-
Add "hisilicon,hi3660-reboot" node for hi3660. Eventually when we've transitioned to UEFI this can be dropped. As we can then use syscon-reboot-mode. Signed-off-by: Chen Feng <puck.chen@hisilicon.com> Signed-off-by: Chen Jun <chenjun14@huawei.com>
-
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
-
This patch adds support for usb on Hikey960. Cc: Chunfeng Yun <chunfeng.yun@mediatek.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: John Stultz <john.stultz@linaro.org> Cc: Binghui Wang <wangbinghui@hisilicon.com> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
Currently the "match_existing_only" of usb_gadget_driver in configfs is set to one which is not flexible. Dwc3 udc will be removed when usb core switch to host mode. This causes failure of writing name of dwc3 udc to configfs's UDC attribuite. To fix this we need to add a way to change the config of "match_existing_only". There are systems like Android do not support udev, so adding "match_existing_only" attribute to allow configuration by user is cost little. This patch adds a configfs attribuite for controling match_existing_only which allow user to config "match_existing_only". Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Binghui Wang <wangbinghui@hisilicon.com> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
This driver handles usb hub power on and typeC port event of HiKey960 board: 1)DP&DM switching between usb hub and typeC port base on typeC port state 2)Control power of usb hub on Hikey960 3)Control vbus of typeC port Cc: Chunfeng Yun <chunfeng.yun@mediatek.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Binghui Wang <wangbinghui@hisilicon.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
The Type-C drivers use USB role switch API to inform the system about the negotiated data role, so registering a role switch in the DRD code in order to support platforms with USB Type-C connectors. Cc: Jun Li <lijun.kernel@gmail.com> Cc: Valentin Schneider <valentin.schneider@arm.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
This patch adds notifier for drivers want to be informed of the usb role switch. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: John Stultz <john.stultz@linaro.org> Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
This patch adds stubs for the exiting functions while CONFIG_USB_ROLE_SWITCH does not enabled. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: John Stultz <john.stultz@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
It needs more time for the device controller to clear the CmdAct of DEPCMD on Hisilicon Kirin Soc. Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Binghui Wang <wangbinghui@hisilicon.com> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
A GCTL soft reset should be executed when switch mode for dwc3 core of Hisilicon Kirin Soc. Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Binghui Wang <wangbinghui@hisilicon.com> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
SPLIT_BOUNDARY_DISABLE should be set for DesignWare USB3 DRD Core of Hisilicon Kirin Soc when dwc3 core act as host. Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Binghui Wang <wangbinghui@hisilicon.com> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
This patch adds support for the poweron and shutdown of dwc3 core on Hisilicon Soc Platform. Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
dt-bindings: misc: Add bindings for HiSilicon usb hub and data role switch functionality on HiKey960 This patch adds binding documentation to support usb hub and usb data role switch of Hisilicon HiKey960 Board. Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Binghui Wang <wangbinghui@hisilicon.com> Signed-off-by: Yu Chen <chenyu56@huawei.com>
-
- Jul 01, 2019
-
-
Douglas Raillard authored
-