linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by David Long

>These days, I believe the separate oprofile backend for ARM has gone >away, and oprofile is implemented using the perf backend anyway. I've been asked to look into this some more. I will post what I learn. -dl

13 years, 8 months

[PATCH] ARM: EXYNOS4: Add machine support for 7" LCD on ORIGEN

by Tushar Behera

ORIGEN board is fitted with 7" LCD panel HV070WSA. The pixel resolution of the LCD panel is 1024x600. Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org> --- The patch is rebased on [1]. But for proper working of LCD on ORIGEN, following patches are needed. a. ARM: EXYNOS4: Add PWM backlight support on Origen http://www.spinics.net/lists/linux-samsung-soc/msg06309.html b. ARM: EXYNOS4: Configure MAX8997 PMIC for Origen http://www.spinics.net/lists/linux-samsung-soc/msg06282.html [1] git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git arch/arm/mach-exynos4/Kconfig | 2 + arch/arm/mach-exynos4/mach-origen.c | 50 +++++++++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig index 48f18f7..8656f49 100644 --- a/arch/arm/mach-exynos4/Kconfig +++ b/arch/arm/mach-exynos4/Kconfig @@ -222,6 +222,8 @@ config MACH_ORIGEN select S3C_DEV_RTC select S3C_DEV_WDT select S3C_DEV_HSMMC2 + select S5P_DEV_FIMD0 + select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_SDHCI help Machine support for ORIGEN based on Samsung EXYNOS4210 diff --git a/arch/arm/mach-exynos4/mach-origen.c b/arch/arm/mach-exynos4/mach-origen.c index ed59f86..f2cea78 100644 --- a/arch/arm/mach-exynos4/mach-origen.c +++ b/arch/arm/mach-exynos4/mach-origen.c @@ -14,16 +14,21 @@ #include <linux/platform_device.h> #include <linux/io.h> #include <linux/input.h> +#include <linux/lcd.h> + +#include <video/platform_lcd.h> #include <asm/mach/arch.h> #include <asm/mach-types.h> #include <plat/regs-serial.h> +#include <plat/regs-fb-v4.h> #include <plat/exynos4.h> #include <plat/cpu.h> #include <plat/devs.h> #include <plat/sdhci.h> #include <plat/iic.h> +#include <plat/fb.h> #include <mach/map.h> @@ -79,10 +84,54 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = { .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL, }; +static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int power) +{ + int gpio = EXYNOS4_GPE3(4); + + gpio_request(gpio, "GPE3_4"); + gpio_direction_output(gpio, power); + gpio_free(gpio); +} + +static struct plat_lcd_data origen_lcd_hv070wsa_data = { + .set_power = lcd_hv070wsa_set_power, +}; + +static struct platform_device origen_lcd_hv070wsa = { + .name = "platform-lcd", + .dev.parent = &s5p_device_fimd0.dev, + .dev.platform_data = &origen_lcd_hv070wsa_data, +}; + +static struct s3c_fb_pd_win origen_fb_win0 = { + .win_mode = { + .left_margin = 64, + .right_margin = 16, + .upper_margin = 64, + .lower_margin = 16, + .hsync_len = 48, + .vsync_len = 3, + .xres = 1024, + .yres = 600, + .refresh = 60, + }, + .max_bpp = 32, + .default_bpp = 24, +}; + +static struct s3c_fb_platdata origen_lcd_pdata __initdata = { + .win[0] = &origen_fb_win0, + .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB, + .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC, + .setup_gpio = exynos4_fimd0_gpio_setup_24bpp, +}; + static struct platform_device *origen_devices[] __initdata = { &s3c_device_hsmmc2, &s3c_device_rtc, &s3c_device_wdt, + &s5p_device_fimd0, + &origen_lcd_hv070wsa, }; static void __init origen_map_io(void) @@ -95,6 +144,7 @@ static void __init origen_map_io(void) static void __init origen_machine_init(void) { s3c_sdhci2_set_platdata(&origen_hsmmc2_pdata); + s5p_fimd0_set_platdata(&origen_lcd_pdata); platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices)); } -- 1.7.4.1

13 years, 8 months

[ACTIVITY] Multimedia WG status report - wk35.2011 (20110829-20110902)

by Ilias Biris

Status report in https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Last week's meeting notes in: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-08-30 == Highlights (details in the status report link above) == - the 1109 planned deliverables are in : https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport#mu… - LJT support for Android has been announced. The existing code needs to be broken into smaller patches to be sent upstream. Backlog in https://launchpad.net/libjpeg-turbo/+milestone/backlog contains a number of blueprints related to that work - bugs work is ongoing: https://bugs.launchpad.net/linaro-ubuntu/+bug/816638 - the kernel side seems to be fixed, looking at the pulseaudio/alsa side of the bug now https://bugs.launchpad.net/linaro-ubuntu/+bug/760919 - patch created and posted https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/746023 - being worked now https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/733334 - probably a duplicate of 746023 - UCM integration is now being tested. Snowball related testing for UCM configuration support may be postponed for after 1109 as snowball ubuntu support for audio still has issues - there is no easy way to test UCM there Please contact me if there are questions, or if you spot something odd/missing in this status report. Best, -- 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, 8 months

Gerrit refs regexp patterns don't work - usefully or at all

by Paul Sokolovsky

Hello, We're elaborating our Linaro Gerrit (2.2.1) set up, and would like to enforce separation between upstream and "our" branches, to disallow stray commits to upstream branches and keep them pullable from AOSP. So, we'd like to limit review requests, pushes, etc. to "refs/heads/for/linaro*" and "refs/heads/linaro*". Trying to enter exactly that into refs entries for All Project's ACL lead to "Invalid Name" error. After looking at Gerrit's source, it turns out that Gerrit expects *-using pattern to end with "/*". Well, why? Yes, it's nice idea to use hierarchical-like branch names. Sometimes. But there're also good reasons to restrict branch name to generic "identifier". For example, to keep one-to-one mapping with filenames (confined to some dirs), or database names (both useful for CI for example). So, requiring slash present before "*" seems like arbitrary restrictions. Anyway, I wasn't too upset, knowing that arbitrary patterns can be encoded using regexps, and that's where real surprises start. First of all, looking at example regexps at http://gerrit.googlecode.com/svn/documentation/2.2.1/access-control.html#_p… there were suspiciously stray backslashes in pattern examples. Anyway, I tried to input "^refs/heads/linaro.*", it was rejected with "Invalid Name" error. Same for "^refs/heads/linaro.*". Then I just tried example from the doc, both as is and with slashes stripped - "\^refs/heads/[a-z]\{1,8\}" & "^refs/heads/[a-z]{1,8}". Same error. Looking at the source, validation for regexp case is complicated (and nothing points to backslashes being required): it seems to generate a subject string which would match entered pattern, and test that simple for being good refs syntax. Well, I thought, maybe UI validation outslies itself, and commit changes directly to project.config of refs/meta/config branch of All-Project. No avail. With config like: [access "^refs/for/refs/linaro.*"] push = group Registered Users it's not possible to submit review against any branch at all. Thinking here would be that may be regexp library is not available, or regexp syntax is not enabled by some option, but just searching reviews with queries like below works just ok: "project:^platform/buil. status:open" "project:^platform/buil.* status:open" "project:^platform/buil.+ status:open" So, I'm stumbled here - what could be wrong, and where to look next? Thanks, 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, 8 months

ARM CPU part numbers

by Andrew Stubbs

Hi all, I'm currently trying to get GCC to auto-detect what CPU to optimize for by finding out what CPU it's actually running on (the user would only have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo. The problem is finding what magic numbers correspond to what CPU. I've found the numbers for A8 and A9 empirically, but I'd like a longer list than that! Does anybody have a list of such numbers? Or else, perhaps people could just post any number they happen to know? I do have a few devices other than A8 and A9 lying around I can look at, but the problem there is I don't actually know for certain what exact CPU model those numbers map to, so confirmed numbers only please. Thanks Andrew

13 years, 8 months

auxv + neon

by Tom Gall

Is a method via the aux vectors to know at runtime if neon is or is not present? Thanks! -- Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox 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, 8 months

[PATCH] ASoC: omap: add MODULE_ALIAS to mcbsp and pcm drivers

by Mans Rullgard

This adds MODULE_ALIAS directives to the omap-mcbsp-dai and omap-pcm-audio drivers so they can be auto-loaded when platform devices are scanned. Signed-off-by: Mans Rullgard <mans.rullgard(a)linaro.org> --- sound/soc/omap/omap-mcbsp.c | 2 ++ sound/soc/omap/omap-pcm.c | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 07b7723..56b7504 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -758,6 +758,8 @@ static int __devexit asoc_mcbsp_remove(struct platform_device *pdev) return 0; } +MODULE_ALIAS("platform:omap-mcbsp-dai"); + static struct platform_driver asoc_mcbsp_driver = { .driver = { .name = "omap-mcbsp-dai", diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index e6a6b99..6c85b69 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -412,6 +412,8 @@ static int __devexit omap_pcm_remove(struct platform_device *pdev) return 0; } +MODULE_ALIAS("platform:omap-pcm-audio"); + static struct platform_driver omap_pcm_driver = { .driver = { .name = "omap-pcm-audio", -- 1.7.6.1

13 years, 8 months

[PATCH] ARM: EXYNOS4: ADD USB EHCI device to SMDKV310

by Sachin Kamat

Signed-off-by: Bhuvana Kakunoori <bhuvana.kakunoori(a)linaro.org> Signed-off-by: Pankaj Dubey <pankaj.dubey(a)samsung.com> Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- arch/arm/mach-exynos4/Kconfig | 2 ++ arch/arm/mach-exynos4/mach-smdkv310.c | 16 ++++++++++++++++ 2 files changed, 18 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig index bb29d51..cc97d23 100644 --- a/arch/arm/mach-exynos4/Kconfig +++ b/arch/arm/mach-exynos4/Kconfig @@ -136,6 +136,7 @@ config MACH_SMDKV310 bool "SMDKV310" select CPU_EXYNOS4210 select S5P_DEV_FIMD0 + select S5P_DEV_USB_EHCI select S3C_DEV_RTC select S3C_DEV_WDT select S3C_DEV_I2C1 @@ -151,6 +152,7 @@ config MACH_SMDKV310 select SAMSUNG_DEV_PWM select EXYNOS4_DEV_SYSMMU select EXYNOS4_SETUP_FIMD0 + select EXYNOS4_SETUP_USB_PHY select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_KEYPAD select EXYNOS4_SETUP_SDHCI diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c index 5f62b2b..b6c28ea 100644 --- a/arch/arm/mach-exynos4/mach-smdkv310.c +++ b/arch/arm/mach-exynos4/mach-smdkv310.c @@ -33,6 +33,8 @@ #include <plat/gpio-cfg.h> #include <plat/backlight.h> #include <plat/mfc.h> +#include <plat/ehci.h> +#include <plat/clock.h> #include <mach/map.h> @@ -167,6 +169,16 @@ static struct i2c_board_info i2c_devs1[] __initdata = { {I2C_BOARD_INFO("wm8994", 0x1a),}, }; +/* USB EHCI */ +static struct s5p_ehci_platdata smdkv310_ehci_pdata; + +static void __init smdkv310_ehci_init(void) +{ + struct s5p_ehci_platdata *pdata = &smdkv310_ehci_pdata; + + s5p_ehci_set_platdata(pdata); +} + static struct platform_device *smdkv310_devices[] __initdata = { &s3c_device_hsmmc0, &s3c_device_hsmmc1, @@ -175,6 +187,7 @@ static struct platform_device *smdkv310_devices[] __initdata = { &s3c_device_i2c1, &s3c_device_rtc, &s3c_device_wdt, + &s5p_device_ehci, &exynos4_device_ac97, &exynos4_device_i2s0, &samsung_device_keypad, @@ -258,6 +271,9 @@ static void __init smdkv310_machine_init(void) samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data); + smdkv310_ehci_init(); + clk_xusbxti.rate = 24000000; + platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices)); s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev; } -- 1.7.4.1

13 years, 8 months

[ACTIVITY] Kernel WG Weekly Status report for week ending 2011-09-02

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status report for the kernel working group for the week ending 2011-08-26. == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-08-29 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-09-01 == Summary, for details see the Status Report == * New kernel process overview doc is being drafted https://docs.google.com/a/linaro.org/document/d/19bqP5akuMCEohb5Ko94emUWBVg… * Submitted pl330 DMA driver device tree support patches for review. * Samsung's uart irq handling patches that move irq handling from platform code to driver is accepted in Greg's tty tree. * Brought up i.mx6q SMP support * Added the support of ARM Dormant/Shutdown mode on i.mx6q * A v3.1-rc2 and device tree based kernel is running on i.mx6q * i.MX code clean up and consolidation: patch-set has been merged to soc tree. * Pushed out v5 of the pinctrl/pinmux subsystem * The bulk of gpio.h cleanup patches have been merged * John Stultz Implemented the proposed config tooling for config fragments, as will be presented at Plumbers conference * Posted kprobes test code to the linux-arm-kernel list. * Improved flash performance use case an simulation programs to provide details of timings so that simulation accuracy can be mor easily judged. * Submitted patches "Remove define CONSISTENT_DMA_SIZE" were pulled by RMK for inclusion in Linux 3.2. * Rebased and resubmitted a patch to get rid of a few StrongARM cache-related build time constants (prerequisite to another patch series removing most instances of <mach/memory.h>) Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

13 years, 8 months

Tracking Android kernel tips and Android builds

by Zach Pfeffer

Now that we have an Android build for every board and Gerrit and LAVA I'd like to unify how we handle kernels for each so that we can work more efficiently, start to unify the kernels and provide a means for external Android users to start to improve these trees. First, since we control the kernels that go into our Android builds I'd like to follow AOSP convention and have: kernel/common.git (john's tree) kernel/imx53.git kernel/omap.git kernel/origen.git kernel/snowball.git (right now we have: panda, beagle <remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="people/jstultz/android" revision="linaro-android-3.0" remote="linaro-other"/> panda-leb <remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="people/andygreen/kernel-tilt" revision="tilt-jstultz-linaro-android-3.0" remote="linaro-other"/> leb-snowball <remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="bsp/st-ericsson/linux-3.0-android-ux500" revision="master" remote="linaro-other"/> leb-origen <remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="people/angus/linux-linaro-3.0" remote="linaro-other" revision="android"/> leb-imx53 <remote fetch="git://git.linaro.org/" name="linaro-other"/> <project name="people/bernhardrosenkranzer/android-kernel-iMX53" path="kernel" remote="linaro-other" revision="3d981d9418c53e3e1a079582088121c641588791"/> ) I'd like these to be at git://android.git.linaro.org/. I'd like to not mirror. Each tree would accept patches via Gerrit and be maintainable through standard git by the tree maintainers. This should allow upgrades to each, without needing to push all the upgrade patches through Gerrit. Next, we'd like to point to a tip branch for each of these trees. This branch would be were development would be happening. Tracking tip is fundamental to continuous integration, if its broken then the primary job of everyone should be getting it going again. I'd like to suggest the branches be named the same and follow John's branch naming convention: linaro-android-3.0...etc Lastly, I'd like to request (and we may be able to automate this once all the kernels are co-located) that once a pinned-manifest.xml comes out, referencing a specific sha1, I'd like to lay a tag on that sha so it sticks around. Its better to tag after the fact because it saves having to do another build/test/qa cycle and will ensure that our pinned-manifest.xml continue to work. I suspect a few growing pains, but I think this is going to be great. Once the kernels are co-located we should be able to look at Gerrit extensions that allow easier upstream patch submission and tracking. We should also be able to more easily refactor things. Using the Gerrit flow and extending it to support Android upstreaming is exactly the thing Linaro was built for. Since Gerrit is such an integral part of Android development, extensions to allow patch propagation would allow a lot of the good work to flow back into the mainline kernel. -Zach

13 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev