Hi Rafael/Srivatsa,
These are some last minute fixes for 3.12. I have found them while looking at
the code to fix the latest suspend/resume crashes we see (Reported by Stephen)..
I believe at some place these are behind those crashes, otherwise people with a
single cluster or single policy couldn't have faced it.. Like Stephen as he was
working on Tegra.
I thought you will wait for my conversation with Srivatsa to get over before
actually applying his patches, but saw that just happened :)
No issues, we can talk a bit more about the problems for now and then you can
get whatever patches are required for 3.12-rc2
First three of the patchset are minor cleanups (you may or may not take them for
3.12), but last two are some real fixes.. I haven't faced any issue without them
but simply found them in code review.
@Stephen: Probably you can try my branch: cpufreq-suspend-fix, which has these
patches without Srivatsa's patches (though some bits of those will also be
required I believe for multicluster systems)..
--
viresh
Viresh Kumar (5):
cpufreq: Remove extra blank line
cpufreq: don't break string in print statements
cpufreq: remove __cpufreq_remove_dev()
cpufreq: don't update policy->cpu while removing while removing other
CPUs
cpufreq: use correct values of cpus in __cpufreq_remove_dev_finish()
drivers/cpufreq/cpufreq.c | 50 +++++++++++++++++++----------------------------
1 file changed, 20 insertions(+), 30 deletions(-)
--
1.7.12.rc2.18.g61b472e
Automated build results for all ARM defconfigs. Summarizes all build
errors, warnings and section mismatches followed by a per-defconfig
summary.
Tree/Branch: linus/master
Git describe: v3.12-rc1-9-gde0bc3d
Commit: de0bc3dfc3 Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile
Build Time: 118 min 36 sec
Passed: 126 / 129 ( 97.67 %)
Failed: 3 / 129 ( 2.33 %)
Errors: 1
Warnings: 17
Section Mismatches: 0
Failed defconfigs:
arm-pxa3xx_defconfig
arm-raumfeld_defconfig
arm-cm_x300_defconfig
Errors:
arm-pxa3xx_defconfig
drivers/mtd/nand/pxa3xx_nand.c:1325:2: error: implicit declaration of function ‘pxa3xx_nand_get_variant’ [-Werror=implicit-function-declaration]
arm-raumfeld_defconfig
drivers/mtd/nand/pxa3xx_nand.c:1325:2: error: implicit declaration of function ‘pxa3xx_nand_get_variant’ [-Werror=implicit-function-declaration]
arm-cm_x300_defconfig
drivers/mtd/nand/pxa3xx_nand.c:1325:2: error: implicit declaration of function ‘pxa3xx_nand_get_variant’ [-Werror=implicit-function-declaration]
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
arm-spitz_defconfig: 1 warnings 0 mismatches
arm-mini2440_defconfig: 1 warnings 0 mismatches
arm-multi_v7_defconfig+lpae.config: 16 warnings 0 mismatches
arm-iop13xx_defconfig: 1 warnings 0 mismatches
arm-corgi_defconfig: 1 warnings 0 mismatches
arm-iop32x_defconfig: 1 warnings 0 mismatches
-------------------------------------------------------------------------------
Errors summary: 1
3 drivers/mtd/nand/pxa3xx_nand.c:1325:2: error: implicit declaration of function ‘pxa3xx_nand_get_variant’ [-Werror=implicit-function-declaration]
Warnings Summary: 17
5 crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 drivers/tty/serial/imx.c:1542:6: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘dma_addr_t’ [-Wformat]
1 drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-sdma.c:1166:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-sdma.c:1092:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:960:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:960:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:930:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:930:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:603:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:593:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:579:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:579:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 arch/arm/mach-omap2/gpmc.c:1495:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘resource_size_t’ [-Wformat]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm-spitz_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
arm-mini2440_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig+lpae.config : PASS, 0 errors, 16 warnings, 0 section mismatches
Warnings:
arch/arm/mach-omap2/gpmc.c:1495:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘resource_size_t’ [-Wformat]
drivers/dma/imx-sdma.c:1092:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-sdma.c:1166:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:579:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:579:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:593:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:603:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:930:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:930:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:960:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:960:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘dma_addr_t’ [-Wformat]
drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘dma_addr_t’ [-Wformat]
drivers/tty/serial/imx.c:1542:6: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
-------------------------------------------------------------------------------
arm-pxa3xx_defconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches
Errors:
drivers/mtd/nand/pxa3xx_nand.c:1325:2: error: implicit declaration of function ‘pxa3xx_nand_get_variant’ [-Werror=implicit-function-declaration]
-------------------------------------------------------------------------------
arm-iop13xx_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
arm-corgi_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
arm-raumfeld_defconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches
Errors:
drivers/mtd/nand/pxa3xx_nand.c:1325:2: error: implicit declaration of function ‘pxa3xx_nand_get_variant’ [-Werror=implicit-function-declaration]
-------------------------------------------------------------------------------
arm-cm_x300_defconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches
Errors:
drivers/mtd/nand/pxa3xx_nand.c:1325:2: error: implicit declaration of function ‘pxa3xx_nand_get_variant’ [-Werror=implicit-function-declaration]
-------------------------------------------------------------------------------
arm-iop32x_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm-realview-smp_defconfig
arm-at91rm9200_defconfig
arm-pcm027_defconfig
arm-rmk-omap3430-ldp.config
arm-bcm2835_defconfig
arm-ixp4xx_defconfig
arm-dove_defconfig
arm-nuc950_defconfig
arm-ebsa110_defconfig
arm-at91sam9261_9g10_defconfig
arm-omap2plus_defconfig
arm-bockw_defconfig
arm-hackkit_defconfig
arm-cns3420vb_defconfig
arm-u300_defconfig
arm-bcm_defconfig
arm-exynos_defconfig
arm-zeus_defconfig
arm-rmk-sa11x0-neponset.config
arm-davinci_all_defconfig
arm-badge4_defconfig
arm-exynos_defconfig+lpae.config
arm-nuc960_defconfig
arm-shark_defconfig
arm-allnoconfig
arm-em_x270_defconfig
arm-armadillo800eva_defconfig
arm-trizeps4_defconfig
arm-acs5k_defconfig
arm-rmk-realview.config
arm-at91sam9260_9g20_defconfig
arm-lpc32xx_defconfig
arm-rmk-omap4430-ldp-allnoconfig.config
arm-rmk-versatile.config
arm-vexpress_defconfig
arm-ape6evm_defconfig
arm-netx_defconfig
arm-socfpga_defconfig
arm-orion5x_defconfig
arm-cm_x2xx_defconfig
arm-da8xx_omapl_defconfig
arm-omap2plus_defconfig+pm.config
arm-at91x40_defconfig
arm-cerfcube_defconfig
arm-versatile_defconfig
arm-am200epdkit_defconfig
arm-rmk-omap3430-ldp-allnoconfig.config
arm-simpad_defconfig
arm-pxa910_defconfig
arm-acs5k_tiny_defconfig
arm-xcep_defconfig
arm-s5pv210_defconfig
arm-at91_dt_defconfig
arm-palmz72_defconfig
arm-ezx_defconfig
arm-imote2_defconfig
arm-netwinder_defconfig
arm-iop33x_defconfig
arm-rmk-pxa.config
arm-assabet_defconfig
arm-magician_defconfig
arm-mainstone_defconfig
arm-s5pc100_defconfig
arm-lager_defconfig
arm-spear3xx_defconfig
arm-shannon_defconfig
arm-at91sam9g45_defconfig
arm-prima2_defconfig
arm-jornada720_defconfig
arm-s3c2410_defconfig
arm-pxa255-idp_defconfig
arm-h3600_defconfig
arm-colibri_pxa270_defconfig
arm-nhk8815_defconfig
arm-viper_defconfig
arm-colibri_pxa300_defconfig
arm-pleb_defconfig
arm-mmp2_defconfig
arm-spear6xx_defconfig
arm-eseries_pxa_defconfig
arm-ks8695_defconfig
arm-imx_v4_v5_defconfig
arm-integrator_defconfig
arm-footbridge_defconfig
arm-pxa168_defconfig
arm-multi_v7_defconfig
arm-s5p64x0_defconfig
arm-rpc_defconfig
arm-mxs_defconfig
arm-nuc910_defconfig
arm-omap1_defconfig
arm-kzm9d_defconfig
arm-rmk-vexpress-ct9x4.config
arm-ep93xx_defconfig
arm-keystone_defconfig
arm-at91sam9rl_defconfig
arm-lubbock_defconfig
arm-s3c6400_defconfig
arm-imx_v6_v7_defconfig
arm-at91sam9263_defconfig
arm-mackerel_defconfig
arm-clps711x_defconfig
arm-collie_defconfig
arm-tegra_defconfig
arm-lart_defconfig
arm-marzen_defconfig
arm-kzm9g_defconfig
arm-tct_hammer_defconfig
arm-mv78xx0_defconfig
arm-realview_defconfig
arm-msm_defconfig
arm-u8500_defconfig
arm-h5000_defconfig
arm-kirkwood_defconfig
arm-mvebu_defconfig
arm-lpd270_defconfig
arm-rmk-omap4430-ldp.config
arm-sama5_defconfig
arm-neponset_defconfig
arm-spear13xx_defconfig
It will be very useful for user space if it has a method of querying
VCPU target type matching to underlying Host. We can use such querying
mechanism and implement machine models in user space where VCPU target
type is always same-as/similar-to underlying Host (i.e. Target CPU=Host).
This patch series implements KVM_ARM_PREFERRED_TARGET ioclt for querying
VCPU target type matching underlying host. Using this new ioctl we can
implement VCPU target CPU=Host in user space (i.e. QEMU/KVMTOOL).
Also, it is not mandatory to call KVM_ARM_PREFERRED_TARGET ioctl and the
old method of trying all possible target types using KVM_ARM_VCPU_INIT
ioctl to initialize VCPU works fine.
Anup Patel (4):
ARM: KVM: Implement kvm_vcpu_preferred_target() function
ARM64: KVM: Implement kvm_vcpu_preferred_target() function
ARM/ARM64: KVM: Implement KVM_ARM_PREFERRED_TARGET ioctl
KVM: Add documentation for KVM_ARM_PREFERRED_TARGET ioctl
Documentation/virtual/kvm/api.txt | 26 ++++++++++++++++++++++----
arch/arm/include/asm/kvm_host.h | 1 +
arch/arm/kvm/arm.c | 12 ++++++++++++
arch/arm/kvm/guest.c | 19 +++++++++++++++++++
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/guest.c | 20 ++++++++++++++++++++
include/uapi/linux/kvm.h | 1 +
7 files changed, 76 insertions(+), 4 deletions(-)
--
1.7.9.5
Quoting Sebastian Capella (2013-08-30 11:42:30)
> Quoting Pavel Machek (2013-08-30 04:35:33)
> > On Mon 2013-08-26 10:40:50, Sebastian Capella wrote:
> > > Quoting Pavel Machek (2013-08-25 08:38:11)
> > > > Is the allocation actually neccessary? At the very least this should
> > > > test for NULL...
> > >
> > > name_to_dev_t expects a non-const name, but the buffer passed in
> > > is const. I also am removing the '\n' if found at the end of the
> > > string which would violate the const.
> >
> > Fix name_to_dev_t, then. No need to do memory allocation just to work
> > around const.
> >
> Hi Pavel,
>
> The issue is really Removing the \n from the user space input. The
> flow is:
> const input buf -> copy to work buffer, remove newline -> name_to_dev_t
>
> ssize_t resume_store(..., const char *buf, size_t n)
> // copy buf, strip off trailing newline, pass to name_to_dev_t
> dev_t name_to_dev_t(char *name)
>
> The const in the restore_store buffer comes from the function type of the
> store member of the kobj_attribute. I don't believe this should be changed.
>
> Currently, name_to_dev_t will fail in some cases if a trailing \n is present.
> Is it more appropriate to handle stripping the newline in the store
> function rather than modifying name_to_dev_t to clean it up?
>
> It seems logical for name_to_dev_t to take a const name parameter as
> there should be no reason to modify the name buffer passed to it.
> I'll be happy to make a patch to do this, but without hardening
> name_to_dev_t against trailing newlines, it would not be neccesary for
> this problem.
>
> Thanks for your time and comments!
>
Hi Pavel,
Do you have any more feedback regarding leaving the strndup?
Thanks!
Sebastian
Automated DT boot report for various ARM defconfigs.
Boot test simply checks if kernel can boot to initramfs with busybox
and run some basic commands (e.g. 'cat /proc/cpuinfo').
Tree/Branch: arm-soc/for-next
Git describe: fixes-for-linus-1444-gab5c3b6
Commit: ab5c3b6b51 Merge tag 'imx-fixes-3.12' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
Failed boot tests (console logs at the end)
===========================================
omap3-beagle: FAIL: arm-omap2plus_defconfig
Full Report
===========
arm-imx_v6_v7_defconfig
-----------------------
imx6dl-wandboard,wand-dual PASS: 0 min 16.3 sec
imx6dl-wandboard,wand-solo PASS: 0 min 16.3 sec
imx6q-wandboard PASS: 0 min 15.1 sec
arm-omap2plus_defconfig
-----------------------
omap3-beagle-xm PASS: 0 min 53.5 sec
am335x-bone PASS: 0 min 26.3 sec
omap3-tobi,3530overo PASS: 0 min 42.3 sec
omap4-panda PASS: 1 min 9.7 sec
omap4-panda-es PASS: 1 min 11.6 sec
omap3-tobi,3730storm PASS: 0 min 41.5 sec
omap3-beagle FAIL: 0 min 18.7 sec
arm-multi_v7_defconfig
----------------------
omap4-panda-es PASS: 1 min 15.3 sec
omap3-beagle-xm PASS: 0 min 51.8 sec
am335x-bone PASS: 0 min 33.4 sec
sun4i-a10-cubieboard PASS: 0 min 11.6 sec
imx6dl-wandboard,wand-solo PASS: 0 min 16.4 sec
omap3-tobi,3530overo PASS: 0 min 44.0 sec
omap4-panda PASS: 1 min 1.8 sec
imx6q-wandboard PASS: 0 min 15.7 sec
omap3-tobi,3730storm PASS: 0 min 40.6 sec
imx6dl-wandboard,wand-dual PASS: 0 min 16.6 sec
omap3-beagle PASS: 0 min 51.0 sec
arm-exynos_defconfig
--------------------
exynos5250-arndale PASS: 0 min 42.8 sec
arm-sama5_defconfig
-------------------
sama5d35ek PASS: 0 min 18.6 sec
Console logs for failures
=========================
arm-omap2plus_defconfig
-----------------------
omap3-beagle: FAIL: last 24 lines of boot log:
----------------------------------------------
OMAP3 beagleboard.org # if test -n ${initenv}; then run initenv; fi
if test -n ${initenv}; then run initenv; fi
OMAP3 beagleboard.org # if test -n ${preboot}; then run preboot; fi
if test -n ${preboot}; then run preboot; fi
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices...
Warning: asx0 using MAC address from net device
1 Ethernet Device(s) found
OMAP3 beagleboard.org # setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
OMAP3 beagleboard.org # dhcp
dhcp
ERROR: Need valid 'usbnet_devaddr' to be set
at ether.c:2369/usb_eth_init()
Waiting for Ethernet connection... done.
BOOTP broadcast 1
BOOTP broadcast 2
~$off
# PYBOOT: Exception: u-boot: ERROR: timed-out getting DHCP address.
# PYBOOT: Time: 18.72 seconds.
# PYBOOT: Result: FAIL
Automated build results for all ARM defconfigs. Summarizes all build
errors, warnings and section mismatches followed by a per-defconfig
summary.
Tree/Branch: arm-soc/for-next
Git describe: fixes-for-linus-1444-gab5c3b6
Commit: ab5c3b6b51 Merge tag 'imx-fixes-3.12' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
Build Time: 119 min 27 sec
Passed: 129 / 129 (100.00 %)
Failed: 0 / 129 ( 0.00 %)
Errors: 0
Warnings: 17
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
arm-spitz_defconfig: 1 warnings 0 mismatches
arm-mini2440_defconfig: 1 warnings 0 mismatches
arm-multi_v7_defconfig+lpae.config: 16 warnings 0 mismatches
arm-iop13xx_defconfig: 1 warnings 0 mismatches
arm-corgi_defconfig: 1 warnings 0 mismatches
arm-iop32x_defconfig: 1 warnings 0 mismatches
-------------------------------------------------------------------------------
Warnings Summary: 17
5 crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 drivers/tty/serial/imx.c:1542:6: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘dma_addr_t’ [-Wformat]
1 drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-sdma.c:1166:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-sdma.c:1092:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:960:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:960:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:930:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:930:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:603:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:593:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:579:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
1 drivers/dma/imx-dma.c:579:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
1 arch/arm/mach-omap2/gpmc.c:1495:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘resource_size_t’ [-Wformat]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm-spitz_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
arm-mini2440_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig+lpae.config : PASS, 0 errors, 16 warnings, 0 section mismatches
Warnings:
arch/arm/mach-omap2/gpmc.c:1495:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘resource_size_t’ [-Wformat]
drivers/dma/imx-sdma.c:1092:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-sdma.c:1166:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:579:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:579:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:593:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:603:4: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:930:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:930:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:960:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/imx-dma.c:960:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘dma_addr_t’ [-Wformat]
drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat]
drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘dma_addr_t’ [-Wformat]
drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘dma_addr_t’ [-Wformat]
drivers/tty/serial/imx.c:1542:6: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
-------------------------------------------------------------------------------
arm-iop13xx_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
arm-corgi_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
arm-iop32x_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
crypto/wp512.c:987:1: warning: the frame size of 1168 bytes is larger than 1024 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm-realview-smp_defconfig
arm-at91rm9200_defconfig
arm-pcm027_defconfig
arm-rmk-omap3430-ldp.config
arm-bcm2835_defconfig
arm-ixp4xx_defconfig
arm-dove_defconfig
arm-nuc950_defconfig
arm-ebsa110_defconfig
arm-at91sam9261_9g10_defconfig
arm-omap2plus_defconfig
arm-bockw_defconfig
arm-hackkit_defconfig
arm-cns3420vb_defconfig
arm-u300_defconfig
arm-bcm_defconfig
arm-exynos_defconfig
arm-imx_v4_v5_defconfig
arm-zeus_defconfig
arm-rmk-sa11x0-neponset.config
arm-davinci_all_defconfig
arm-badge4_defconfig
arm-exynos_defconfig+lpae.config
arm-nuc960_defconfig
arm-shark_defconfig
arm-allnoconfig
arm-em_x270_defconfig
arm-armadillo800eva_defconfig
arm-trizeps4_defconfig
arm-acs5k_defconfig
arm-rmk-realview.config
arm-at91sam9260_9g20_defconfig
arm-lpc32xx_defconfig
arm-rmk-omap4430-ldp-allnoconfig.config
arm-rmk-versatile.config
arm-vexpress_defconfig
arm-ape6evm_defconfig
arm-netx_defconfig
arm-socfpga_defconfig
arm-orion5x_defconfig
arm-cm_x2xx_defconfig
arm-da8xx_omapl_defconfig
arm-omap2plus_defconfig+pm.config
arm-at91x40_defconfig
arm-cerfcube_defconfig
arm-versatile_defconfig
arm-am200epdkit_defconfig
arm-rmk-omap3430-ldp-allnoconfig.config
arm-simpad_defconfig
arm-pxa910_defconfig
arm-acs5k_tiny_defconfig
arm-xcep_defconfig
arm-s5pv210_defconfig
arm-at91_dt_defconfig
arm-palmz72_defconfig
arm-ezx_defconfig
arm-imote2_defconfig
arm-netwinder_defconfig
arm-iop33x_defconfig
arm-rmk-pxa.config
arm-assabet_defconfig
arm-magician_defconfig
arm-mainstone_defconfig
arm-s5pc100_defconfig
arm-lager_defconfig
arm-spear3xx_defconfig
arm-shannon_defconfig
arm-at91sam9g45_defconfig
arm-prima2_defconfig
arm-jornada720_defconfig
arm-s3c2410_defconfig
arm-pxa255-idp_defconfig
arm-h3600_defconfig
arm-colibri_pxa270_defconfig
arm-nhk8815_defconfig
arm-nuc910_defconfig
arm-viper_defconfig
arm-colibri_pxa300_defconfig
arm-pleb_defconfig
arm-mmp2_defconfig
arm-spear6xx_defconfig
arm-eseries_pxa_defconfig
arm-ks8695_defconfig
arm-raumfeld_defconfig
arm-integrator_defconfig
arm-footbridge_defconfig
arm-pxa168_defconfig
arm-multi_v7_defconfig
arm-s5p64x0_defconfig
arm-rpc_defconfig
arm-mxs_defconfig
arm-pxa3xx_defconfig
arm-omap1_defconfig
arm-kzm9d_defconfig
arm-rmk-vexpress-ct9x4.config
arm-ep93xx_defconfig
arm-keystone_defconfig
arm-at91sam9rl_defconfig
arm-lubbock_defconfig
arm-s3c6400_defconfig
arm-imx_v6_v7_defconfig
arm-at91sam9263_defconfig
arm-mackerel_defconfig
arm-clps711x_defconfig
arm-collie_defconfig
arm-tegra_defconfig
arm-lart_defconfig
arm-marzen_defconfig
arm-kzm9g_defconfig
arm-tct_hammer_defconfig
arm-mv78xx0_defconfig
arm-realview_defconfig
arm-msm_defconfig
arm-u8500_defconfig
arm-cm_x300_defconfig
arm-h5000_defconfig
arm-kirkwood_defconfig
arm-mvebu_defconfig
arm-lpd270_defconfig
arm-rmk-omap4430-ldp.config
arm-sama5_defconfig
arm-neponset_defconfig
arm-spear13xx_defconfig
Hi all,
This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism, and is
rebased on linux-3.12-rc1
The purpose of this framework is to provide not only buffer access
control to CPU and CPU, and CPU and DMA, and DMA and DMA but also
easy-to-use interfaces for device drivers and user application.
In addtion, this patch set suggests a way for enhancing performance.
Changelog v9:
- Delete only one sync object matched at DEL_OBJ_FROM_RSV macro.
- Fix memory leak issue at dmabuf_sync_single_lock()
Changelog v8:
Consider the write-and-then-read ordering pointed out by David Herrmann,
- The ordering issue means that a task don't take a lock to the dmabuf
so this task would be stalled even though this task requested a lock to
the dmabuf between other task unlocked and tries to lock the dmabuf
again. For this, we have added a wait event mechanism using only generic
APIs, wait_event_timeout and wake_up functions.
The below is how to handle the ordering issue using this mechanism:
1. Check if there is a sync object added prior to current task's one.
2. If exists, it unlocks the dmabuf so that other task can take a lock
to the dmabuf first.
3. Wait for the wake up event from other task: current task will be
waked up when other task unlocks the dmabuf.
4. Take a lock to the dmabuf again.
- Code cleanups.
Changelog v7:
Fix things pointed out by Konrad Rzeszutek Wilk,
- Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL.
- Make sure to unlock and unreference all dmabuf objects
when dmabuf_sync_fini() is called.
- Add more comments.
- Code cleanups.
Changelog v6:
- Fix sync lock to multiple reads.
- Add select system call support.
. Wake up poll_wait when a dmabuf is unlocked.
- Remove unnecessary the use of mutex lock.
- Add private backend ops callbacks.
. This ops has one callback for device drivers to clean up their
sync object resource when the sync object is freed. For this,
device drivers should implement the free callback properly.
- Update document file.
Changelog v5:
- Rmove a dependence on reservation_object: the reservation_object is used
to hook up to ttm and dma-buf for easy sharing of reservations across
devices. However, the dmabuf sync can be used for all dma devices; v4l2
and drm based drivers, so doesn't need the reservation_object anymore.
With regared to this, it adds 'void *sync' to dma_buf structure.
- All patches are rebased on mainline, Linux v3.10.
Changelog v4:
- Add user side interface for buffer synchronization mechanism and update
descriptions related to the user side interface.
Changelog v3:
- remove cache operation relevant codes and update document file.
Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.
For generic user mode interface, we have used fcntl and select system
call[3]. As you know, user application sees a buffer object as a dma-buf
file descriptor. So fcntl() call with the file descriptor means to lock
some buffer region being managed by the dma-buf object. And select() call
means to wait for the completion of CPU or DMA access to the dma-buf
without locking. For more detail, you can refer to the dma-buf-sync.txt
in Documentation/
There are some cases user-space process needs this buffer synchronization
framework. One of which is to primarily enhance GPU rendering performance
in case that 3D app draws somthing in a buffer using CPU, and other process
composes the buffer with its own backbuffer using GPU.
In case of 3D app, the app calls glFlush to submit 3d commands to GPU driver
instead of glFinish for more performance. The reason, we call glFlush, is
that glFinish blocks caller's task until the execution of the 3d commands is
completed. So that makes GPU and CPU more idle. As a result, 3d rendering
performance with glFinish is quite lower than glFlush.
However, the use of glFlush has one issue that the the buffer shared with
GPU could be broken when CPU accesses the buffer just after glFlush because
CPU cannot be aware of the completion of GPU access to the buffer.
Of course, the app can be aware of that time using eglWaitGL but this function
is valid only in case of the same context.
The below summarizes how app's window is displayed on Tizen[4] platform:
1. X client requests a window buffer to Xorg.
2. X client draws something in the window buffer using CPU.
3. X client requests SWAP to Xorg.
4. Xorg notifies a damage event to Composite Manager.
5. Composite Manager gets the window buffer (front buffer) through
DRI2GetBuffers.
6. Composite Manager composes the window buffer and its own back buffer
using GPU. At this time, eglSwapBuffers is called: internally, 3d
commands are flushed to gpu driver.
7. Composite Manager requests SWAP to Xorg.
8. Xorg performs drm page flip. At this time, the window buffer is
displayed on screen.
Web app based on HTML5 also has the same issue. Web browser and Web app
are different process. The Web app can draw something in its own buffer using
CPU, and then the Web Browser can compose the buffer with its own back buffer.
Thus, in such cases, a shared buffer could be broken as one process draws
something in a buffer using CPU, when other process composes the buffer with
its own buffer using GPU without any locking mechanism. That is why we need
user land locking interface, fcntl system call.
And last one is a deferred page flip issue. This issue is that a window
buffer rendered can be displayed on screen in about 32ms in worst case:
assume that the gpu rendering is completed within 16ms.
That can be incurred when compositing a pixmap buffer with a window buffer
using GPU and when vsync is just started. At this time, Xorg waits for
a vblank event to get a window buffer so 3d rendering will be delayed
up to about 16ms. As a result, the window buffer would be displayed in
about two vsyncs (about 32ms) and in turn, that would show slow
responsiveness.
For this, we could enhance the responsiveness with locking mechanism: skipping
one vblank wait. I guess Android, Chrome OS, and other platforms are using
their own locking mechanisms with similar reason; Android sync driver, KDS, and
DMA fence.
The below shows the deferred page flip issue in worst case:
|------------ <- vsync signal
|<------ DRI2GetBuffers
|
|
|
|------------ <- vsync signal
|<------ Request gpu rendering
time |
|
|<------ Request page flip (deferred)
|------------ <- vsync signal
|<------ Displayed on screen
|
|
|
|------------ <- vsync signal
Thanks,
Inki Dae
References:
[1] http://lwn.net/Articles/470339/
[2] https://patchwork.kernel.org/patch/2625361/
[3] http://linux.die.net/man/2/fcntl
[4] https://www.tizen.org/
Inki Dae (2):
dmabuf-sync: Add a buffer synchronization framework
dma-buf: Add user interfaces for dmabuf sync support
Documentation/dma-buf-sync.txt | 286 ++++++++++++
drivers/base/Kconfig | 7 +
drivers/base/Makefile | 1 +
drivers/base/dma-buf.c | 86 ++++
drivers/base/dmabuf-sync.c | 951 ++++++++++++++++++++++++++++++++++++++++
include/linux/dma-buf.h | 16 +
include/linux/dmabuf-sync.h | 257 +++++++++++
7 files changed, 1604 insertions(+)
create mode 100644 Documentation/dma-buf-sync.txt
create mode 100644 drivers/base/dmabuf-sync.c
create mode 100644 include/linux/dmabuf-sync.h
--
1.7.9.5
Hi Linaro,
I am trying to attach interrupt handlers to the push buttons on the
arndale board.
Your patch adds in dts information on the push buttons
menu {
+ label = "SW-TACT2";
+ gpios = <&gpx1 4 1>;
+ linux,code = <139>;
+ gpio-key,wakeup;
+ };
I assume that <139> is the GPU number in base 10. Is this correct ?
Also what is the significance of gpx1 and 4 1 ?
As per my understanding if 139 the GPIO number then it should be
mapped to a GPIO register where the state Input/ouput/Interrupt has to
be set.
I am not able to find that register in the
"Exynos_5_Dual_User_Manaul_Public_REV100-0", All I could find a set of
GPXXXX registers but no mapping between <139> and those registers.
Can anyone explain the steps, on how to associate the push button to INT (IRQ)
Thanks in Advance..
-mj
__cpufreq_governor() returns with -EBUSY when governor is already stopped and we
try to stop it again, but when it is stopped we must not allow calls to
CPUFREQ_GOV_LIMITS event as well.
This patch adds this check in __cpufreq_governor().
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Hi Rafael,
Its better if we can get these in for 3.11, otherwise we need to get them in the
stable tree..
Anyway, we will get these in 3.10 stable tree but that requires us to identify
few more patches that will go with these. I will do that later.
This must fix the issues reported by Stephen.
Tested on my thinkpad over your linux-next branch.
drivers/cpufreq/cpufreq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5c75e31..f320a20 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1692,8 +1692,9 @@ static int __cpufreq_governor(struct cpufreq_policy *policy,
policy->cpu, event);
mutex_lock(&cpufreq_governor_lock);
- if ((!policy->governor_enabled && (event == CPUFREQ_GOV_STOP)) ||
- (policy->governor_enabled && (event == CPUFREQ_GOV_START))) {
+ if ((policy->governor_enabled && (event == CPUFREQ_GOV_START)) ||
+ (!policy->governor_enabled && ((event == CPUFREQ_GOV_LIMITS) ||
+ (event == CPUFREQ_GOV_STOP)))) {
mutex_unlock(&cpufreq_governor_lock);
return -EBUSY;
}
--
1.7.12.rc2.18.g61b472e
From: Mark Brown <broonie(a)linaro.org>
Help ensure that updates to the Samsung device trees get sent to the
Samsung maintainers for review by adding file patterns to MAINTAINERS.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6d0dabe..8a0c044 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1154,6 +1154,8 @@ L: linux-arm-kernel(a)lists.infradead.org (moderated for non-subscribers)
L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers)
W: http://www.fluff.org/ben/linux/
S: Maintained
+F: arch/arm/boot/s3c*
+F: arch/arm/boot/exynos*
F: arch/arm/plat-samsung/
F: arch/arm/mach-s3c24*/
F: arch/arm/mach-s3c64xx/
--
1.8.4.rc3