linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Updated Pulse Audio + alsa-lib for 11.12

by Tom Gall

Hi Ricardo, With working HDMI output on the original panda board, and Wei's new release of patches to alsa-lib and pulseaudio, I've updated both alsa-lib and pulseaudio for 11.12 in ppa:linaro-maintainers/overlay. Sound on the panda over HDMI from my testing works out of the box. It's not perfect but it works. I will repeat this same test with my imx53 shortly. For all on the dev list, be aware that audio is in a state of flux and while we'd like to avoid defects they are likely. The Multimedia WG is putting substantial effort into having a "just works" level of quality for supported boards. A very bit thank you is in order for Wei Feng for his hard work on 11.12! Good job! One small sound for an ARM board, but a big noise for Linaro when we can say, "It just works." -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

13 years, 10 months

Linaro Android testing for Pandaboard

by Alan Chuang

Hi All: Since Panda board is now officially supported by Google, I decided to do a quick testing between Linaro build (release 11.11 - v2.3.7), Linaro ICS preview (v4.0.1) and Google's ICS build for Panda-board (v4.0.1). Here are what I found: 1. Google's ICS build detects the resolution to be 672(H)x1280(W) on my monitor while Linaro builds default to 480x640. I manually changed the screen resolution in boot.scr to be omapfb.mode=dvi:1280x672MR-24@60. The linaro ICS preview can now come up with 672x1280 resolution, but I encountered graph driver crash in 11.11 release (v2.3.7). The video output came out on HDMI port for 11.11 release instead of DVI port as in Linaro ICS previous & Google's ICS build. This seems to tell me that there is a problem with graphic driver in 11.11 official release and EDID detection is not working for Linaro builds. 2. I ran Sunspider & 0xbench in Linaro ICS preview (in 480x640 resolution) & Google's ICS build for Panda-board (in 1280x672 resolution). Linaro ICS preview has slightly better result in Sunspider testing, but falls significantly behind in 0xbench. Changing the resolution to 1280x672 on the Linaro ICS preview build shows noticeable lag in UI performance. This seems to suggest that Linaro ICS preview doesn't enable GPU. I simply followed the instructions in the release note to populate SD cards with proper images for testing. Has anyone done similar testing? Is the above observation consistent with your result? Thanks, Alan Chuang -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

13 years, 10 months

Patches to compile ICS with the 4.6 toolchain

by Tony Mansson

Hi, Bero's patches to compile ICS with the 4.6 toolchain are available in an easy to use package. They are released to http://releases.linaro.org/11.12/components/android/ics-gcc-patches/ /Tony

13 years, 10 months

[ACTIVITY] Status of memory management closing 11.12

by Ilias Biris

Hi folks, I went ahead and checked what is the status of the UMM effort as 2011 is closing to an end. What follows is my attempt to summarise the status, collating the pieces from the latest announcements and changelogs and having discussed it briefly with Jesse and Rob. Feel free to comment if there is something missing or not correct: A. CMA - Contiguous memory allocator. This is in its v17 incarnation at the moment (a v18 is in preparation but not released yet). v17 shares the code with memory compaction subsystem, not the hotplug like it was before (change has been suggested by Mel Gorman) and there are also a few fixes here and there, like addressing most of the comments from Andrew Morton and Mel Gorman in the rest of the CMA code, fixing broken initialization on ARM systems with DMA zone enabled and rebasing the code on v3.2-rc2 kernel. An issue has been noted in linaro-dev from the TI landing team : without any highmem the code is working great, but with HIGHMEM inclusion of the CMA v17 consistently causes failure during DMA init. This is expected to be fixed soon (perhaps in v18?). In meantime it is suggested using 2G/2G memory split as a workaround (Kernel Features -> Memory split -> 2G/2G user/kernel split). B. dma mapping API - DMA-mapping framework redesign for ARM architecture: this is in the v4 now. It includes a few minor changes since last version. The changes are mainly on the IOMMU mapper, keeping the DMA-mapping redesign patches almost unchanged. The code is rebased onto v3.2-rc4 kernel + IOMMU/next branch to include latest changes from IOMMU kernel tree. This series also contains support for mapping with pages larger than 4KiB using new, extended IOMMU API, and did a general cleanup of the DMA mapping implementation. However it seems that this patchset "attempts to fix everyone at once". It has been suggested that instead of trying to do that the implementation should give sufficient transition period - for example just adding the new methods now and only removing them in the following merge window when all the architectures have had a chance to migrate. C. dmabuf - a DMA-buf object sharing framework: this is now in its 3rd version. The newest version incorporates changes as requested during the review, such as - replacing BUG_ON with WARN_ON at various places, removing mmap() fop and dma_buf_op, also the sg_sync* operations, and documenting that mmap is not allowed for exported buffer, adding error checks, replacing EXPORT_SYMBOL with EXPORT_SYMBOL_GPL and fixing some cosmetic/documentation items. There are still some items under discusion such as userspace mmap support, more advanced (and more strictly specified) coherency models and shared infrastructure for implementing exporters. However, there is a suggestion that these items will become much clearer once we have a few example drivers at hand and a better understanding of what cases need to be handled better. D. Finally some repositories - where can you find the code to try it out: * git://git.linaro.org/people/jessebarker/linaro-mm-sig/linux.git contains (for the moment) 6 branches: + cma-v17 == unadulterated v3.2-rc4 + cma v17 patchset + dma-mapping-v4 == unadulterated v3.2-rc4 + dma-mapping v4 patchset + android-cma-v17 == john stultz's androidization tree based upon unadulterated v3.2-rc4 + cma v17 patchset + android-dma-mapping-v4 == john stultz's androidization tree based upon unadulterated v3.2-rc4 + dma-mapping v4 patchset Also note these repos: - https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf contains patches to enable sharing of buffers between drm and v4l2, Rob commented that it isn't really identified yet which tree to push dmabuf through.. airlied has volunteered to push via drm tree, which is ok - git://git.linaro.org/people/bgaignard/linux-snowball-cma-test.git contains a first version of the CMA testing scripts for LAVA (snowball specific at least for now) Best regards, -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

13 years, 10 months

[ANN] Automated upstream syncing for Linaro Android tree

by Paul Sokolovsky

Hello, This should have gone more than a week ago, but was "lost" in click-thru work. Anyway, we now finally have automatic syncing with upstreams for our tree - that includes AOSP and other components we mirror. It runs for more than 2 weeks now and works pretty well. For AOSP, some components may be missing with upstream version upgrades, then just please submit a ticket to have them picked up (manual op), like this one: https://bugs.launchpad.net/linaro-android-infrastructure/+bug/905664 to ensure timely processing. Thanks, and Merry Christmas! Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 10 months

Is Pandaboard cpuhotplug working stably?

by Barry Song

Hi guys, i tried cpuhotplug on pandaboard for both Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to work stably. On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well: # echo 0 > /sys/devices/system/cpu/cpu1/online CPU1: shutdown if i enable the cpu1 again by "echo 1 > /sys/devices/system/cpu/cpu1/online", the system will restore to 3 random status: hang, normal, panic. Using Linaro 11.11 release, "echo 0 > /sys/devices/system/cpu/cpu1/online" will make system hang and the whole system will not be able to reset by pressing reset key, the only way to reset system is pulling out AV power. i am sorry i can't get more time to debug and find more clues. just want to ask people whether this is a version the cpuhotplug works normal on? Thanks barry

13 years, 10 months

[PATCH] ohci-hcd: ohci-hcd: use usleep_range() instead of mdelay()

by Dmitry Antipov

From ac60fe289eef3d81009f2b14a12acbac3e71878b Mon Sep 17 00:00:00 2001 From: Dmitry Antipov <dmitry.antipov(a)linaro.org> Date: Wed, 21 Dec 2011 11:05:27 +0400 Subject: [PATCH] ohci-hcd: use usleep_range() instead of mdelay() --- drivers/usb/host/ohci-hcd.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index b263919..a6d58da 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -574,6 +574,7 @@ static int ohci_run (struct ohci_hcd *ohci) u32 mask, val; int first = ohci->fminterval == 0; struct usb_hcd *hcd = ohci_to_hcd(ohci); + unsigned long usecs; disable (ohci); @@ -724,7 +725,8 @@ retry: spin_unlock_irq (&ohci->lock); // POTPGT delay is bits 24-31, in 2 ms units. - mdelay ((val >> 23) & 0x1fe); + usecs = ((val >> 23) & 0x1fe) * USEC_PER_MSEC; + usleep_range(usecs, usecs + 1000); hcd->state = HC_STATE_RUNNING; if (quirk_zfmicro(ohci)) { -- 1.7.7.4

13 years, 11 months

audio support for pandboard on Linaro release 11.11/12

by Yuping Luo

Hi, I have one pandboard (4430), however, it's said the audio and audiohw not supported in the Linaro android release 11.11 or 11.12, so is there one way to add the support manually ? if yes, where to begin ? I am also interested in enabling the video hw support for the board, but no idea until now. Thanks. Yuping Luo

13 years, 11 months

[PATCH V3 0/7] add a generic cpufreq driver

by Richard Zhao

The driver support single core and multi core ARM SoCs. For multi core, it assume all cores share the same clock and voltage. TODO: - Add each core seperate freq/volt support (MSM). Changes in v3: - move adjusting smp loops_per_jiffy to arm common code, and also adjust global loops_per_jiffy. - remove adjusting loops_per_jiffy in imx and omap cpufreq drivers. - check compatible "generic-cpufreq" when module_init - change printk to pr_xxx - add generic-cpufreq DT binding doc Changes in v2: - add volatage change support - change '_' in property name to '-' - use initial value to calculate loops_per_jiffy - fix reading cpu_volts property bug - let cpufreq_frequency_table_cpuinfo routines handle cpu_freq_khz_max/min - don't change freq in arm_cpufreq_exit, because every core share the same freq. - use unsigned long describe frequency as much as possible. Because clk use unsigned long, but cpufreq use unsigned int. [PATCH V3 1/7] ARM: add cpufreq transiton notifier to adjust [PATCH V3 2/7] arm/imx: cpufreq: remove loops_per_jiffy recalculate [PATCH V3 3/7] cpufreq: OMAP: remove loops_per_jiffy recalculate for [PATCH V3 4/7] cpufreq: add generic cpufreq driver [PATCH V3 5/7] dts/imx6q: add cpufreq property [PATCH V3 6/7] arm/imx6q: register arm_clk as cpu to clkdev [PATCH V3 7/7] arm/imx6q: select ARCH_HAS_CPUFREQ

13 years, 11 months

[PATCH] drm: fix compilation warning with i386_defconfig

by Tushar Behera

The patch d795e2c "Adding omap_gpu drm display driver" introduces following compilation warning when the kernel is compiled for x86 architecture (i386_defconfig). Also the kernel compilation is unsuccessful because of calls to omap specific platform header files. warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS) The problem is fixed by making DRM_OMAP depend on ARCH_OMAP2. Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org> --- drivers/gpu/drm/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index fdef87b..0949995 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -169,7 +169,7 @@ config DRM_SAVAGE config DRM_OMAP tristate "OMAP GPU (EXPERIMENTAL)" - depends on DRM && !CONFIG_FB_OMAP2 + depends on DRM && ARCH_OMAP2 && !CONFIG_FB_OMAP2 select DRM_KMS_HELPER select OMAP2_VRAM select OMAP2_DSS -- 1.7.1

13 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev