linaro-kernel

linaro-kernel@lists.linaro.org

10094 discussions

arm-soc/for-next build: 0 failures 17 warnings (fixes-for-linus-1444-gab5c3b6)

by Kevin Hilman build bot

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

11 years, 7 months

[PATCH v9 0/2] Introduce buffer synchronization framework

by Inki Dae

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

11 years, 7 months

Re:[V3,3/7] ARM: dts: Add gpio-button entries for Arndale board

by MJ embd

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

11 years, 7 months

[PATCH 1/2] cpufreq: don't allow governor limits to be changed when it is disabled

by Viresh Kumar

__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

11 years, 7 months

[PATCH] MAINTAINERS: Add DTS files to patterns for Samsung platform

by Mark Brown

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

11 years, 7 months

[PATCH V2 1/2] cpufreq: unlock correct rwsem while updating policy->cpu

by Viresh Kumar

Current code looks like this: WARN_ON(lock_policy_rwsem_write(cpu)); update_policy_cpu(policy, new_cpu); unlock_policy_rwsem_write(cpu); {lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's rwsem. Because cpu is changing with the call to update_policy_cpu(), the unlock_policy_rwsem_write() will release the incorrect lock. The right solution would be to release the same lock as was taken earlier. Also update_policy_cpu() was also called from cpufreq_add_dev() without any locks and so its better if we move this locking to inside update_policy_cpu(). Reported-and-Tested-by: Jon Medhurst<tixy(a)linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- Hi Rafael, Only one patch is sent now as other one is unchanged. drivers/cpufreq/cpufreq.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 43c24aa..1479522 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -952,9 +952,20 @@ static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu) if (cpu == policy->cpu) return; + /* + * Take direct locks as lock_policy_rwsem_write wouldn't work here. + * Also lock for last cpu is enough here as contention will happen only + * after policy->cpu is changed and after it is changed, other threads + * will try to acquire lock for new cpu. And policy is already updated + * by then. + */ + down_write(&per_cpu(cpu_policy_rwsem, policy->cpu)); + policy->last_cpu = policy->cpu; policy->cpu = cpu; + up_write(&per_cpu(cpu_policy_rwsem, policy->last_cpu)); + #ifdef CONFIG_CPU_FREQ_TABLE cpufreq_frequency_table_update_policy_cpu(policy); #endif @@ -1203,9 +1214,7 @@ static int __cpufreq_remove_dev_prepare(struct device *dev, new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen); if (new_cpu >= 0) { - WARN_ON(lock_policy_rwsem_write(cpu)); update_policy_cpu(policy, new_cpu); - unlock_policy_rwsem_write(cpu); if (!frozen) { pr_debug("%s: policy Kobject moved to cpu: %d " -- 1.7.12.rc2.18.g61b472e

11 years, 8 months

[PATCH 1/2] cpufreq: unlock correct rwsem while updating policy->cpu

by Viresh Kumar

Current code looks like this: WARN_ON(lock_policy_rwsem_write(cpu)); update_policy_cpu(policy, new_cpu); unlock_policy_rwsem_write(cpu); {lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's rwsem. Because cpu is changing with the call to update_policy_cpu(), the unlock_policy_rwsem_write() will release the incorrect lock. The right solution would be to take rwsem lock/unlock for both old and new cpu. This patch fixes this bug by taking both locks directly instead of calling lock_policy_rwsem_write(). Reported-by: Jon Medhurst<tixy(a)linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- Hi Rafael, Probably we can get this patch in for 3.12? The second one can go in 3.13. These are compile tested only at my end. Tixy reported these and probably can give his tested-by once he is done testing them. drivers/cpufreq/cpufreq.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 43c24aa..c18bf7b 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -952,9 +952,16 @@ static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu) if (cpu == policy->cpu) return; + /* take direct locks as lock_policy_rwsem_write wouldn't work here */ + down_write(&per_cpu(cpu_policy_rwsem, policy->cpu)); + down_write(&per_cpu(cpu_policy_rwsem, cpu)); + policy->last_cpu = policy->cpu; policy->cpu = cpu; + up_write(&per_cpu(cpu_policy_rwsem, cpu)); + up_write(&per_cpu(cpu_policy_rwsem, policy->cpu)); + #ifdef CONFIG_CPU_FREQ_TABLE cpufreq_frequency_table_update_policy_cpu(policy); #endif @@ -1203,9 +1210,7 @@ static int __cpufreq_remove_dev_prepare(struct device *dev, new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen); if (new_cpu >= 0) { - WARN_ON(lock_policy_rwsem_write(cpu)); update_policy_cpu(policy, new_cpu); - unlock_policy_rwsem_write(cpu); if (!frozen) { pr_debug("%s: policy Kobject moved to cpu: %d " -- 1.7.12.rc2.18.g61b472e

11 years, 8 months

next/master boot: 23 pass, 0 fail (next-20130917)

by Kevin Hilman build bot

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: next/master Git describe: next-20130917 Commit: 2a65ef5e5e Add linux-next specific files for 20130917 Full Report =========== arm-imx_v6_v7_defconfig ----------------------- imx6dl-wandboard,wand-dual PASS: 0 min 16.4 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.4 sec imx6q-wandboard PASS: 0 min 15.0 sec arm-omap2plus_defconfig ----------------------- omap3-beagle-xm PASS: 0 min 48.1 sec am335x-bone PASS: 0 min 31.3 sec omap3-tobi,3530overo PASS: 0 min 42.6 sec omap4-panda PASS: 1 min 3.5 sec omap4-panda-es PASS: 1 min 9.8 sec omap3-tobi,3730storm PASS: 0 min 41.6 sec omap3-beagle PASS: 0 min 53.4 sec arm-multi_v7_defconfig ---------------------- omap4-panda-es PASS: 1 min 11.7 sec omap3-beagle-xm PASS: 0 min 52.0 sec am335x-bone PASS: 0 min 33.4 sec sun4i-a10-cubieboard PASS: 0 min 11.5 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.4 sec omap3-tobi,3530overo PASS: 0 min 40.9 sec omap4-panda PASS: 1 min 1.6 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.7 sec omap3-beagle PASS: 0 min 48.2 sec arm-exynos_defconfig -------------------- exynos5250-arndale PASS: 0 min 33.6 sec arm-sama5_defconfig ------------------- sama5d35ek PASS: 0 min 18.6 sec

11 years, 8 months

next/master build: 0 failures 17 warnings (next-20130917)

by Kevin Hilman build bot

Automated build results for all ARM defconfigs. Summarizes all build errors, warnings and section mismatches followed by a per-defconfig summary. Tree/Branch: next/master Git describe: next-20130917 Commit: 2a65ef5e5e Add linux-next specific files for 20130917 Build Time: 119 min 10 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/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-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/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

11 years, 8 months

arm-soc/for-next boot: 21 pass, 2 fail (fixes-for-linus-3-ga534298)

by Kevin Hilman build bot

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-3-ga534298 Commit: a534298a0c mtd: nand: pxa3xx: Remove unneeded ifdef CONFIG_OF Failed boot tests (console logs at the end) =========================================== imx6dl-wandboard,wand-solo: FAIL: arm-imx_v6_v7_defconfig 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 FAIL: 0 min 11.4 sec imx6q-wandboard PASS: 0 min 15.1 sec arm-omap2plus_defconfig ----------------------- omap3-beagle-xm PASS: 0 min 51.3 sec am335x-bone PASS: 0 min 26.8 sec omap3-tobi,3530overo PASS: 0 min 42.9 sec omap4-panda PASS: 1 min 4.0 sec omap4-panda-es PASS: 1 min 10.1 sec omap3-tobi,3730storm PASS: 0 min 41.8 sec omap3-beagle FAIL: 0 min 18.8 sec arm-multi_v7_defconfig ---------------------- omap4-panda-es PASS: 1 min 8.0 sec omap3-beagle-xm PASS: 0 min 52.5 sec am335x-bone PASS: 0 min 33.7 sec sun4i-a10-cubieboard PASS: 0 min 14.5 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.4 sec omap3-tobi,3530overo PASS: 0 min 41.2 sec omap4-panda PASS: 1 min 1.1 sec imx6q-wandboard PASS: 0 min 15.8 sec omap3-tobi,3730storm PASS: 0 min 41.0 sec imx6dl-wandboard,wand-dual PASS: 0 min 16.6 sec omap3-beagle PASS: 0 min 51.6 sec arm-exynos_defconfig -------------------- exynos5250-arndale PASS: 0 min 29.6 sec arm-sama5_defconfig ------------------- sama5d35ek PASS: 0 min 18.3 sec Console logs for failures ========================= arm-imx_v6_v7_defconfig ----------------------- imx6dl-wandboard,wand-solo: FAIL: last 24 lines of boot log: ------------------------------------------------------------ [<80301c94>] (platform_drv_probe+0x0/0x24) from [<8030095c>] (driver_probe_device+0x10c/0x224) [<80300850>] (driver_probe_device+0x0/0x224) from [<80300b08>] (__driver_attach+0x94/0x98) r7:00000000 r6:9f904044 r5:808175f8 r4:9f904010 [<80300a74>] (__driver_attach+0x0/0x98) from [<802feda0>] (bus_for_each_dev+0x5c/0x90) r6:80300a74 r5:808175f8 r4:00000000 r3:9f83b55c [<802fed44>] (bus_for_each_dev+0x0/0x90) from [<80300450>] (driver_attach+0x20/0x28) r6:80805548 r5:9f126300 r4:808175f8 [<80300430>] (driver_attach+0x0/0x28) from [<802fff90>] (bus_add_driver+0xdc/0x264) [<802ffeb4>] (bus_add_driver+0x0/0x264) from [<803011cc>] (driver_register+0x80/0xfc) r8:807ba0b8 r7:8078c46c r6:80825980 r5:00000006 r4:808175f8 [<8030114c>] (driver_register+0x0/0xfc) from [<80301ed0>] (__platform_driver_register+0x50/0x64) r5:00000006 r4:807da588 [<80301e80>] (__platform_driver_register+0x0/0x64) from [<807ba0d0>] (sdhci_esdhc_imx_driver_init+0x18/0x20) [<807ba0b8>] (sdhci_esdhc_imx_driver_init+0x0/0x20) from [<80008898>] (do_one_initcall+0xf4/0x154) [<800087a4>] (do_one_initcall+0x0/0x154) from [<8078cc10>] (kernel_init_freeable+0x104/0x1d0) [<8078cb0c>] (kernel_init_freeable+0x0/0x1d0) from [<805b6c8c>] (kernel_init+0x10/0xec) [<805b6c7c>] (kernel_init+0x0/0xec) from [<8000e978>] (ret_from_fork+0x14/0x3c) r4:00000000 r3:ffffffff Code: e89da800 e1a0c00d e92dd818 e24cb004 (e5903000) ---[ end trace be4dd5231a9da743 ]--- Kernel panic - not ~$off # PYBOOT: Exception: kernel: ERROR: failed to boot: Kernel panic # PYBOOT: Time: 11.43 seconds. # PYBOOT: Result: FAIL arm-omap2plus_defconfig ----------------------- omap3-beagle: FAIL: last 24 lines of boot log: ---------------------------------------------- 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 BOOTP broadcast 3 ~$off # PYBOOT: Exception: u-boot: ERROR: timed-out getting DHCP address. # PYBOOT: Time: 18.79 seconds. # PYBOOT: Result: FAIL

11 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel