Tree/Branch: next-20170109
Git describe: next-20170109
Commit: c84d0bbe09 Add linux-next specific files for 20170109
Build Time: 104 min 14 sec
Passed: 9 / 10 ( 90.00 %)
Failed: 1 / 10 ( 10.00 %)
Errors: 1
Warnings: 3
Section Mismatches: 0
Failed defconfigs:
arm-allmodconfig
Errors:
arm-allmodconfig
../drivers/net/ethernet/ti/netcp_core.c:1951:28: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : arm64-allmodconfig
2 warnings 0 mismatches : arm-allmodconfig
-------------------------------------------------------------------------------
Errors summary: 1
1 ../drivers/net/ethernet/ti/netcp_core.c:1951:28: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
Warnings Summary: 3
2 ../drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num' may be used uninitialized in this function [-Wmaybe-uninitialized]
2 ../drivers/pinctrl/pinctrl-amd.c:172:21: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/power/supply/axp20x_usb_power.c:297:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
../drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/pinctrl/pinctrl-amd.c:172:21: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/power/supply/axp20x_usb_power.c:297:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 1 errors, 2 warnings, 0 section mismatches
Errors:
../drivers/net/ethernet/ti/netcp_core.c:1951:28: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
Warnings:
../drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/pinctrl/pinctrl-amd.c:172:21: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
Hello,
Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are represented by positive
integer values, a lower value represents lower performance state.
We had some discussions about it in the past on the PM list [1], which is
followed by discussions during the LPC. The outcome of all that was that we
should extend Power Domain framework to support active state power management
as well.
The power-domains until now were only concentrating on the idle state
management of the device and this needs to change in order to reuse the
infrastructure of power domains for active state management.
To get a complete picture of the proposed plan, following is what we
need to do:
- Create DT bindings to get domain performance state information for the
platforms.
- Enhance OPP framework to parse these and call into the PM Qos
framework with a performance state request.
- Enhance PM Qos framework to provide the API to be used by consumers
(or OPP framework) and pass it on to the (Generic) Power Domain
framework.
- Enhance Generic Power Domain framework to accept such requests,
accumulate all belonging to a single power domain and call domain
driver specific callback with the performance state we want for the
domain.
- The domain driver shall then, in a platform specific way, set the
requested performance level.
- Note that these features are applicable to the CPU, GPU and other IIO
or non-IIO devices.
- There can be cases where a device can choose between multiple power
domains based on what performance level we want for the device. In
such cases, we should represent the multiplexer with a separate power
domain. In effect, the device (or OPP table) will correspond to a
single power domain, but the backend driver of that domain shall
implement the multiplexing functionality.
This patchset implements the very first part of this chain and
introduces a new optional property for the consumers of the
power-domains: domain-performance-state. This property can be used
directly by the consumer or its OPP table.
V1->V2:
- The performance states get their own nodes as they can have multiple
values.
- Allow optional property domain-microvolt for the performance states
--
viresh
[1] https://marc.info/?l=linux-pm&m=147747923708075&w=2
Viresh Kumar (2):
PM / Domains: Introduce domain-performance-states binding
PM / OPP: Introduce domain-performance-state binding to OPP nodes
Documentation/devicetree/bindings/opp/opp.txt | 59 ++++++++++++++++++
.../devicetree/bindings/power/power_domain.txt | 69 ++++++++++++++++++++++
2 files changed, 128 insertions(+)
--
2.7.1.410.g6faf27b
version 5:
- rebased on drm-for-v4.10 tag
- set get_unmapped_area field if FB_PROVIDE_GET_FB_UNMAPPED_AREA is
defined
- since version 4 dma_mmap_wc() issue will be fixed on architecture side,
either by my patch (submitted, under review)
http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
or by what is doing Vladimir about noMMU support on Cortex-M:
http://www.spinics.net/lists/arm-kernel/msg548764.html
version 4:
- add documentation about drm_gem_cma_get_unmapped_area()
- introduce FB_PROVIDE_GET_FB_UNMAPPED_AREA configuration flag for get_fb_unmapped_area()
- I have also send the first patch (https://lkml.org/lkml/2016/12/1/308) to make dma_mmap_wc
works on ARM noMMU platform, assuming that is patch will be accepted there is no more
needs to call vm_ioremap in cma helpers.
version 3:
- split the original patch in 3 parts, it should be more easy to review like
this.
- duplicate drm_fb_cma_helper.c and drm_gem_cma_helper.c into nommu version
- add a configuration flag for drm_vm.c
There are some MCU platforms, like stm32f4, which don't have MMU
but have hardware display IP where is it possible to implement a
drm/kms driver.
Obviously that start by removing MMU configuration flag from Kconfig.
But while coding the driver for stm32f4 (on discovery board to have enough memory)
we have already identify few other pieces of code that need to be change.
We have been inspired by what already exist in v4l2 where using mmuless devices
is possible.
Since we have only use cma helpers we only have partial view of what could be
needed for other part of drm/kms framework.
Benjamin Gaignard (3):
fbmem: add a default get_fb_unmapped_area function
drm: compile drm_vm.c only when needed
drm: allow to use mmuless SoC
Documentation/gpu/drm-mm.rst | 11 ++++++
drivers/gpu/drm/Kconfig | 9 ++++-
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_gem_cma_helper.c | 71 ++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/drm_legacy.h | 7 ++++
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/video/fbdev/Kconfig | 8 ++++
drivers/video/fbdev/core/fbmem.c | 18 ++++++++-
include/drm/drm_gem_cma_helper.h | 17 +++++++++
9 files changed, 141 insertions(+), 4 deletions(-)
--
1.9.1