linaro-dev January 2012

linaro-dev@lists.linaro.org

125 participants
124 discussions

by Dave Martin

For everyone who packages kernel trees: I've had some questions about getting the source for linaro kernel packaged, and it seems that this is still not straightforward: Getting the debian package source (i.e., flat tarball) for a binary kernel is possible, but only if it is a non-superseded version. Working out which source package you need is non-obvious (You have to check for installed kernel packages, and guess which source package you need, based on that. Non-linaro folks may not understand the difference between the various meta- and real kernel packages and may get pretty confused along the way.) Finding the git tree and the relevant commit to reproduce the source (including that for superseded kernels) is hard or impossible. It requires guesswork and/or specific knowledge about the way the relevant team manages their trees. For some platforms, it looks like there may be no single tree containing the packaged kernel at all, in which case you would also need more guesswork and/or scripts or help from the relevant landing team in order actually to reproduce a release. Am I correct in these conclusions? If so, here's a proposal -- I welcome people's comments (and please do say if any of these problems are actually solved already!): For every binary kernel package (.deb) publicly released by any linaro team, including those produced by the platform team and the landing teams: 1) The source package's control file must contain a Vcs-Git entry 2) The Vcs-Git entry must reference a git tree which contains the _exact_ source code which appears in the source package. * Such a tree must exist and must be publicly readable. It does not have to be on git.linaro.org (though this is the recommended place). * Referring to git://git.linaro.org/ubuntu/linux-linaro.git is not acceptable, unless that repo is populated with the real source for that specific kernel as well as the packaging. * Manufacturing the source package from the contents of multiple repositories or branches at source package upload time is not acceptable, unless the result is also recorded as a tagged commit in the repository referenced by the Vcs-Git entry in the debian/control file contained in that same commit. The commit must have full history: importing tarballs directly into a repository for the purpose of release tagging is not acceptable. * Referring to a tree which does not contain the whole contents of the debian source package (for example, debian/ and other packaging files/dirs are missing) is not acceptable. 3) Tagging of packaged kernels must be done in a standard way. * I recommend <source package name>_<package version>, matching the Source field of debian/control and the version number of the most recent debian/changelog entry respectively (which must both be present in the repository as a consequence of (2)). If we want to avoid namespace pollution, we probably want to add a prefix such as debian/ or ubuntu/ to the tag name to indicate that the tag describes the source for a published .deb package. If so, we must standardise that prefix so that it is identical in all out trees. * Tree maintainers are of course free to add any other additional tags for their own use if they want to. All teams already do release tagging of some sort, but the lack of consistency creates difficulties when anyone from outside the team tries to understand that team's trees. * We _could_ standardise the following, but it is not essential: * ubuntu/<release>: The tagged source for the _original_ kernel which was distributed in <release> (where <release> is a linaro monthly release such as 11.12 or 12.01) 4) No specific branch naming requirements exist. * Release tags do not necessarily need to appear on any branch. * We _could_ standardise the following, but it is not essential: * ubuntu/latest - the tagged packaged source for the most recent kernel release made from this tree (In the above, we could choose a diferent prefix instead of ubuntu/, but as described in (3) ,this should be chosen globally and _not_ on a per-tree basis). Cheers ---Dave

12 years, 11 months

[PATCH] TRATS: Fix uart gpio config

by Chander Kashyap

It updates the missing gpio configuration of UART port. Signed-off-by: Chander Kashyap <chander.kashyap(a)linaro.org> Cc: HeungJun, Kim <riverful.kim(a)samsung.com> --- board/samsung/trats/trats.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c index f795ff0..4c9773d 100644 --- a/board/samsung/trats/trats.c +++ b/board/samsung/trats/trats.c @@ -337,7 +337,7 @@ static void board_uart_init(void) int i; /* UART0-UART1 GPIOs (part1) : 0x22222222 */ - for (i = 0; i < 7; i++) { + for (i = 0; i < 8; i++) { s5p_gpio_set_pull(&gpio1->a0, i, GPIO_PULL_NONE); s5p_gpio_cfg_pin(&gpio1->a0, i, GPIO_FUNC(0x2)); } @@ -347,7 +347,7 @@ static void board_uart_init(void) * GPA1CON[3] = I2C_3_SCL (3) * GPA1CON[2] = I2C_3_SDA (3) */ - for (i = 0; i < 5; i++) { + for (i = 0; i < 6; i++) { s5p_gpio_set_pull(&gpio1->a1, i, GPIO_PULL_NONE); s5p_gpio_cfg_pin(&gpio1->a1, i, GPIO_FUNC((i == 2 || i == 3) ? 0x3 : 0x2)); -- 1.7.5.4

12 years, 11 months

Ubuntu LEB 12.01 RC images

by Ricardo Salveti

Hey folks, Just like to announce the Ubuntu LEB 12.01 RC images, and the pointers for people that want to check the testing progress and such (or even helping testing them). Currently we're tracking our test cases at https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu (most of them requires manual effort at the moment, but we're improving that with LAVA in the following weeks). If you think about any other important test case that we might be missing here, please let me know and we can add it at our testing cycle. You can find all the 12.01 RC builds (for all boards and image flavors) at http://snapshots.linaro.org/oneiric/, with build id 20120123-1. For our four main boards we also have a testing spreadsheet, were we publish the official release testing, done by the dev plat engineers. You can find the links at https://wiki.linaro.org/Platform/DevPlatform/Testing (note that you can find the bug reports from the test cases by looking at the QA page tag links). Fathi will be coordinating all respin requests in the next following days at linaro-release m-l, and the final image will be published this thursday, at releases.linaro.org. Please also be sure to publish any bug report with the RC images against https://launchpad.net/linaro-ubuntu, or just contact us at #linaro @ freenode (https://wiki.linaro.org/MeetTheTeam#Developer_Platform). Thanks, -- Ricardo Salveti de Araujo

12 years, 11 months

Staging Android kernel sources

by Frederik Lotter

Dear Linaro, I am using the image from your staging distribution or ICS Android: http://releases.linaro.org/11.12/android/images/staging-panda/ I would like to build the latest Streamline gator driver, and gatord daemon. I had a look at the GIT repo but I am afraid this is too complex for me to find what I need (http://git.linaro.org/gitweb). (1) Could you please advise where I would find the matching kernel (a) sources and (b) config for Panda? ----------- On a similar note, I am also running the latest Ubuntu (Panda) distribution. I was recently updated to kernel version v3.1.1.8 (linaro-lt-omap) using "update-manager". (2) Could you also help me to find the sources for this version (or any version used in the Linaro Ubuntu distributions for that matter). If there is a way to apt-get the sources that would be very useful to know as well. Any help would be much appreciated. Best Regards, Frederik Lotter ****************************************************************** Frederik Lotter, Application Engineer at ARM Ltd. UK Support Team....: +44 (0)1223 400600 US Support Team....: +1 512 381 2928 110 Direct Dial........: +44 (0)1223 400549 Email..............: Frederik.Lotter(a)arm.com ****************************************************************** -- 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.

12 years, 11 months

Announcement: Linaro Connect Q2.12

by Stephen Doel

Hi All, I'm excited to confirm that Linaro Connect Q2.12 will be held from 28 May - 1 June 2012 at the Gold Coast Hotel in Hong Kong. This will be Linaro's first major event in Asia, and quite possibly the largest Linux on ARM event to be hosted in that part of the world. As well as being a convenient location for many of our Member engineers, its also in good proximity to a number of ARM's leading Cortex-A licensees and reflects the growing importance of that region to ARM open source software development. The event website is now available on our main Connect website, and when registration and hotel bookings open I will send you an updated e-mail: http://connect.linaro.org/events/event/linaro-connect-q2-12/ Thx Stephen Doel Chief Operating Officer T: +44 1223 45 00 23 │ M: +44 77 66 014 247 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro/155974581091106> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog

12 years, 11 months

[PATCH] hrtimers, timers: eliminate some jiffies-backed code

by Dmitry Antipov

This patch provides an attempt to get away from jiffies in msleep() and msleep_interruptible() to hrtimers-backed usleep_range() and usleep_range_interruptible(). Both of the latter now returns an amount of microseconds really spent in sleep; another rationale for this was to convert msleep()-based wait-for-hardware loops to usleep_range(), like this: unsigned long timeout = jiffies + msecs_to_jiffies(1000); while (hw_is_not_ready()) { if (time_after(jiffies, timeout)) return -ETIMEDOUT; msleep(1); } to: unsigned long timeout = 0; while (hw_is_not_ready()) { if (timeout > USEC_PER_SEC) return -ETIMEDOUT; timeout += usleep_range(500, 1500); } Signed-off-by: Dmitry Antipov <dmitry.antipov(a)linaro.org> --- fs/eventpoll.c | 3 ++- fs/select.c | 3 ++- include/linux/delay.h | 3 ++- include/linux/hrtimer.h | 8 +++++--- ipc/mqueue.c | 4 ++-- kernel/hrtimer.c | 38 +++++++++++++++++++++++++++++++------- kernel/timer.c | 39 +++++++++++++++++++++++++-------------- 7 files changed, 69 insertions(+), 29 deletions(-) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index aabdfc3..a374944 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1349,7 +1349,8 @@ fetch_events: } spin_unlock_irqrestore(&ep->lock, flags); - if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS)) + if (!schedule_hrtimeout_range(to, NULL, slack, + HRTIMER_MODE_ABS)) timed_out = 1; spin_lock_irqsave(&ep->lock, flags); diff --git a/fs/select.c b/fs/select.c index d33418f..b4354b2 100644 --- a/fs/select.c +++ b/fs/select.c @@ -236,7 +236,8 @@ int poll_schedule_timeout(struct poll_wqueues *pwq, int state, set_current_state(state); if (!pwq->triggered) - rc = schedule_hrtimeout_range(expires, slack, HRTIMER_MODE_ABS); + rc = schedule_hrtimeout_range(expires, NULL, slack, + HRTIMER_MODE_ABS); __set_current_state(TASK_RUNNING); /* diff --git a/include/linux/delay.h b/include/linux/delay.h index a6ecb34..bad6d49 100644 --- a/include/linux/delay.h +++ b/include/linux/delay.h @@ -45,7 +45,8 @@ extern unsigned long lpj_fine; void calibrate_delay(void); void msleep(unsigned int msecs); unsigned long msleep_interruptible(unsigned int msecs); -void usleep_range(unsigned long min, unsigned long max); +unsigned long usleep_range(unsigned long min, unsigned long max); +unsigned long usleep_range_interruptible(unsigned long min, unsigned long max); static inline void ssleep(unsigned int seconds) { diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h index fd0dc30..01d782b 100644 --- a/include/linux/hrtimer.h +++ b/include/linux/hrtimer.h @@ -126,6 +126,7 @@ struct hrtimer { * task is set to NULL, when the timer expires. */ struct hrtimer_sleeper { + ktime_t kt; struct hrtimer timer; struct task_struct *task; }; @@ -428,9 +429,10 @@ extern long hrtimer_nanosleep_restart(struct restart_block *restart_block); extern void hrtimer_init_sleeper(struct hrtimer_sleeper *sl, struct task_struct *tsk); -extern int schedule_hrtimeout_range(ktime_t *expires, unsigned long delta, - const enum hrtimer_mode mode); -extern int schedule_hrtimeout_range_clock(ktime_t *expires, +extern int schedule_hrtimeout_range(ktime_t *expires, ktime_t *elapsed, + unsigned long delta, + const enum hrtimer_mode mode); +extern int schedule_hrtimeout_range_clock(ktime_t *expires, ktime_t *elapsed, unsigned long delta, const enum hrtimer_mode mode, int clock); extern int schedule_hrtimeout(ktime_t *expires, const enum hrtimer_mode mode); diff --git a/ipc/mqueue.c b/ipc/mqueue.c index 9b7c8ab..e57d7c1 100644 --- a/ipc/mqueue.c +++ b/ipc/mqueue.c @@ -449,8 +449,8 @@ static int wq_sleep(struct mqueue_inode_info *info, int sr, set_current_state(TASK_INTERRUPTIBLE); spin_unlock(&info->lock); - time = schedule_hrtimeout_range_clock(timeout, 0, - HRTIMER_MODE_ABS, CLOCK_REALTIME); + time = schedule_hrtimeout_range_clock(timeout, NULL, + 0, HRTIMER_MODE_ABS, CLOCK_REALTIME); while (ewp->state == STATE_PENDING) cpu_relax(); diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index ae34bf5..8642c3f 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -1475,6 +1475,12 @@ static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer) struct hrtimer_sleeper *t = container_of(timer, struct hrtimer_sleeper, timer); struct task_struct *task = t->task; + struct hrtimer_clock_base *base; + unsigned long flags; + + base = lock_hrtimer_base(timer, &flags); + t->kt = ktime_sub(base->get_time(), t->kt); + unlock_hrtimer_base(timer, &flags); t->task = NULL; if (task) @@ -1485,6 +1491,13 @@ static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer) void hrtimer_init_sleeper(struct hrtimer_sleeper *sl, struct task_struct *task) { + struct hrtimer_clock_base *base; + unsigned long flags; + + base = lock_hrtimer_base(&sl->timer, &flags); + sl->kt = base->get_time(); + unlock_hrtimer_base(&sl->timer, &flags); + sl->timer.function = hrtimer_wakeup; sl->task = task; } @@ -1747,12 +1760,14 @@ void __init hrtimers_init(void) /** * schedule_hrtimeout_range_clock - sleep until timeout * @expires: timeout value (ktime_t) + * @elapsed: pointer to ktime_t used to save time spent in sleep * @delta: slack in expires timeout (ktime_t) * @mode: timer mode, HRTIMER_MODE_ABS or HRTIMER_MODE_REL * @clock: timer clock, CLOCK_MONOTONIC or CLOCK_REALTIME */ int __sched -schedule_hrtimeout_range_clock(ktime_t *expires, unsigned long delta, +schedule_hrtimeout_range_clock(ktime_t *expires, ktime_t *elapsed, + unsigned long delta, const enum hrtimer_mode mode, int clock) { struct hrtimer_sleeper t; @@ -1763,6 +1778,8 @@ schedule_hrtimeout_range_clock(ktime_t *expires, unsigned long delta, */ if (expires && !expires->tv64) { __set_current_state(TASK_RUNNING); + if (elapsed) + *elapsed = ktime_set(0, 0); return 0; } @@ -1772,6 +1789,8 @@ schedule_hrtimeout_range_clock(ktime_t *expires, unsigned long delta, if (!expires) { schedule(); __set_current_state(TASK_RUNNING); + if (elapsed) + *elapsed = ktime_set(KTIME_SEC_MAX, 0); return -EINTR; } @@ -1787,6 +1806,9 @@ schedule_hrtimeout_range_clock(ktime_t *expires, unsigned long delta, if (likely(t.task)) schedule(); + if (elapsed) + *elapsed = t.kt; + hrtimer_cancel(&t.timer); destroy_hrtimer_on_stack(&t.timer); @@ -1798,6 +1820,7 @@ schedule_hrtimeout_range_clock(ktime_t *expires, unsigned long delta, /** * schedule_hrtimeout_range - sleep until timeout * @expires: timeout value (ktime_t) + * @elapsed: pointer to ktime_t used to save time spent in sleep * @delta: slack in expires timeout (ktime_t) * @mode: timer mode, HRTIMER_MODE_ABS or HRTIMER_MODE_REL * @@ -1823,17 +1846,19 @@ schedule_hrtimeout_range_clock(ktime_t *expires, unsigned long delta, * * Returns 0 when the timer has expired otherwise -EINTR */ -int __sched schedule_hrtimeout_range(ktime_t *expires, unsigned long delta, +int __sched schedule_hrtimeout_range(ktime_t *expires, ktime_t *elapsed, + unsigned long delta, const enum hrtimer_mode mode) { - return schedule_hrtimeout_range_clock(expires, delta, mode, - CLOCK_MONOTONIC); + return schedule_hrtimeout_range_clock(expires, elapsed, delta, + mode, CLOCK_MONOTONIC); } EXPORT_SYMBOL_GPL(schedule_hrtimeout_range); /** * schedule_hrtimeout - sleep until timeout * @expires: timeout value (ktime_t) + * @elapsed: pointer to ktime_t used to save time spent in sleep * @mode: timer mode, HRTIMER_MODE_ABS or HRTIMER_MODE_REL * * Make the current task sleep until the given expiry time has @@ -1853,9 +1878,8 @@ EXPORT_SYMBOL_GPL(schedule_hrtimeout_range); * * Returns 0 when the timer has expired otherwise -EINTR */ -int __sched schedule_hrtimeout(ktime_t *expires, - const enum hrtimer_mode mode) +int __sched schedule_hrtimeout(ktime_t *expires, const enum hrtimer_mode mode) { - return schedule_hrtimeout_range(expires, 0, mode); + return schedule_hrtimeout_range(expires, NULL, 0, mode); } EXPORT_SYMBOL_GPL(schedule_hrtimeout); diff --git a/kernel/timer.c b/kernel/timer.c index a297ffc..00acab6 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -1796,12 +1796,12 @@ void __init init_timers(void) */ void msleep(unsigned int msecs) { - unsigned long timeout = msecs_to_jiffies(msecs) + 1; + unsigned long usecs = msecs * USEC_PER_MSEC; + unsigned long slack = rt_task(current) ? 0 : + current->timer_slack_ns / NSEC_PER_USEC; - while (timeout) - timeout = schedule_timeout_uninterruptible(timeout); + usleep_range(usecs, usecs + slack); } - EXPORT_SYMBOL(msleep); /** @@ -1810,23 +1810,27 @@ EXPORT_SYMBOL(msleep); */ unsigned long msleep_interruptible(unsigned int msecs) { - unsigned long timeout = msecs_to_jiffies(msecs) + 1; + unsigned long timeout, usecs, slack; - while (timeout && !signal_pending(current)) - timeout = schedule_timeout_interruptible(timeout); - return jiffies_to_msecs(timeout); -} + timeout = 0; + usecs = msecs * USEC_PER_MSEC; + slack = rt_task(current) ? 0 : current->timer_slack_ns / NSEC_PER_USEC; + while (timeout < usecs && !signal_pending(current)) + timeout += usleep_range_interruptible(usecs, usecs + slack); + return timeout / USEC_PER_MSEC; +} EXPORT_SYMBOL(msleep_interruptible); -static int __sched do_usleep_range(unsigned long min, unsigned long max) +static inline unsigned long do_usleep_range(unsigned long min, unsigned long max) { - ktime_t kmin; + ktime_t kmin, elapsed; unsigned long delta; kmin = ktime_set(0, min * NSEC_PER_USEC); delta = (max - min) * NSEC_PER_USEC; - return schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL); + return schedule_hrtimeout_range(&kmin, &elapsed, delta, HRTIMER_MODE_REL) + ? 0 : ktime_to_us(elapsed); } /** @@ -1834,9 +1838,16 @@ static int __sched do_usleep_range(unsigned long min, unsigned long max) * @min: Minimum time in usecs to sleep * @max: Maximum time in usecs to sleep */ -void usleep_range(unsigned long min, unsigned long max) +unsigned long usleep_range(unsigned long min, unsigned long max) { __set_current_state(TASK_UNINTERRUPTIBLE); - do_usleep_range(min, max); + return do_usleep_range(min, max); } EXPORT_SYMBOL(usleep_range); + +unsigned long usleep_range_interruptible(unsigned long min, unsigned long max) +{ + __set_current_state(TASK_INTERRUPTIBLE); + return do_usleep_range(min, max); +} +EXPORT_SYMBOL(usleep_range_interruptible); -- 1.7.7.5

12 years, 11 months

[PATCH v5 0/4] Add SMDK5250 board support

by Chander Kashyap

This patchset add support for Samsung's SMDK5250 board based on EXYNOS5250 based SoC. It also adds support for MMC SPL booting. The porting is done by Samsung engineers at HQ in System LSI Team. I am contributing in upstreaming the code for the board. Based upon discussions following patches are dropped in this version: Exynos: Add CONFIG_EXYNOS4 Macro to EXYNOS4 based boards Exynos: Clock.c: Replace exynos4 prefix with exynos SMDK5250: enable device tree support is squashed with EXYNOS: Add SMDK5250 board support Chander Kashyap (4): Exynos: Clock.c: Use CONFIG_SYS_CLK_FREQ macro ARM: EXYNOS: Add support for Exynos5 based SoCs EXYNOS: Add SMDK5250 board support EXYNOS: SMDK5250: Add MMC SPL support MAINTAINERS | 1 + arch/arm/cpu/armv7/exynos/clock.c | 214 ++++++++++- arch/arm/include/asm/arch-exynos/clock.h | 326 ++++++++++++++++ arch/arm/include/asm/arch-exynos/cpu.h | 35 ++- arch/arm/include/asm/arch-exynos/dmc.h | 146 +++++++ arch/arm/include/asm/arch-exynos/gpio.h | 99 +++++- arch/arm/include/asm/arch-exynos/tzpc.h | 52 +++ board/samsung/smdk5250/Makefile | 67 ++++ board/samsung/smdk5250/clock_init.c | 202 ++++++++++ board/samsung/smdk5250/dmc_init.c | 508 +++++++++++++++++++++++++ board/samsung/smdk5250/lowlevel_init.S | 96 +++++ board/samsung/smdk5250/mmc_boot.c | 58 +++ board/samsung/smdk5250/setup.h | 353 +++++++++++++++++ board/samsung/smdk5250/smdk5250.c | 150 ++++++++ board/samsung/smdk5250/tools/mkexynos_image.c | 117 ++++++ board/samsung/smdk5250/tzpc_init.c | 48 +++ boards.cfg | 1 + include/configs/s5pc210_universal.h | 1 + include/configs/smdk5250.h | 202 ++++++++++ include/configs/trats.h | 1 + 20 files changed, 2660 insertions(+), 17 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/dmc.h create mode 100644 arch/arm/include/asm/arch-exynos/tzpc.h create mode 100644 board/samsung/smdk5250/Makefile create mode 100644 board/samsung/smdk5250/clock_init.c create mode 100644 board/samsung/smdk5250/dmc_init.c create mode 100644 board/samsung/smdk5250/lowlevel_init.S create mode 100644 board/samsung/smdk5250/mmc_boot.c create mode 100644 board/samsung/smdk5250/setup.h create mode 100644 board/samsung/smdk5250/smdk5250.c create mode 100644 board/samsung/smdk5250/tools/mkexynos_image.c create mode 100644 board/samsung/smdk5250/tzpc_init.c create mode 100644 include/configs/smdk5250.h -- 1.7.5.4

12 years, 11 months

[PATCH v4 0/4] Add SMDK5250 board support

by Chander Kashyap

This patchset add support for Samsung's SMDK5250 board based on EXYNOS5250 based SoC. It also adds support for MMC SPL booting. The porting is done by Samsung engineers at HQ in System LSI Team. I am contributing in upstreaming the code for the board. Based upon discussions following patches are dropped in this version: Exynos: Add CONFIG_EXYNOS4 Macro to EXYNOS4 based boards Exynos: Clock.c: Replace exynos4 prefix with exynos SMDK5250: enable device tree support is squashed with EXYNOS: Add SMDK5250 board support Chander Kashyap (4): Exynos: Clock.c: Use CONFIG_SYS_CLK_FREQ macro ARM: EXYNOS: Add support for Exynos5 based SoCs EXYNOS: Add SMDK5250 board support EXYNOS: SMDK5250: Add MMC SPL support MAINTAINERS | 1 + arch/arm/cpu/armv7/exynos/clock.c | 214 ++++++++++- arch/arm/include/asm/arch-exynos/clock.h | 326 ++++++++++++++++ arch/arm/include/asm/arch-exynos/cpu.h | 35 ++- arch/arm/include/asm/arch-exynos/dmc.h | 146 +++++++ arch/arm/include/asm/arch-exynos/gpio.h | 99 +++++- arch/arm/include/asm/arch-exynos/tzpc.h | 52 +++ board/samsung/smdk5250/Makefile | 67 ++++ board/samsung/smdk5250/clock_init.c | 202 ++++++++++ board/samsung/smdk5250/dmc_init.c | 508 +++++++++++++++++++++++++ board/samsung/smdk5250/lowlevel_init.S | 96 +++++ board/samsung/smdk5250/mmc_boot.c | 58 +++ board/samsung/smdk5250/setup.h | 353 +++++++++++++++++ board/samsung/smdk5250/smdk5250.c | 152 ++++++++ board/samsung/smdk5250/tools/mkexynos_image.c | 117 ++++++ board/samsung/smdk5250/tzpc_init.c | 48 +++ boards.cfg | 1 + include/configs/s5pc210_universal.h | 1 + include/configs/smdk5250.h | 202 ++++++++++ include/configs/trats.h | 1 + 20 files changed, 2662 insertions(+), 17 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/dmc.h create mode 100644 arch/arm/include/asm/arch-exynos/tzpc.h create mode 100644 board/samsung/smdk5250/Makefile create mode 100644 board/samsung/smdk5250/clock_init.c create mode 100644 board/samsung/smdk5250/dmc_init.c create mode 100644 board/samsung/smdk5250/lowlevel_init.S create mode 100644 board/samsung/smdk5250/mmc_boot.c create mode 100644 board/samsung/smdk5250/setup.h create mode 100644 board/samsung/smdk5250/smdk5250.c create mode 100644 board/samsung/smdk5250/tools/mkexynos_image.c create mode 100644 board/samsung/smdk5250/tzpc_init.c create mode 100644 include/configs/smdk5250.h -- 1.7.5.4

12 years, 11 months

Release frequency: a discussion for Linaro Connect Q1.12?

by Gregoire Gentil

Hello, I'm Grégoire Gentil, the founder of Always Innovating. I intend to participate to Linaro Connect Q1.12 though I'm not part of this organization. I follow the work of Linaro and I find it very interesting for our OMAP-based products such as the HDMI Dongle: http://www.alwaysinnovating.com. I don't know if it's the right forum or if such discussion has already taken place, but there is one point that I would like to raise up: release frequency. Linaro is currently on a one-month period, which is very tight. To my mind, such small period presents two disadvantages, long-term perspective and innovation: - if there is a new release every month, it's hard to know which release is *very* stable and should be used by an external company which might not have the same frenzy to update all the time. - Regarding innovation, Linaro might learn from the Ubuntu experience. Mark Shuttleworth was a strong advocate of the strict Ubuntu short release schedule and he admitted later that a too frequent period prevents from innovating. When you are pressed by a schedule, it's hard for the organization to step back and take the time to break-through on a novel approach. The point of my email is not to convince Linaro to change the current situation but to bring an idea for a complementary approach at least for the first point: for instance, let's imagine a Linaro "super-stable once sometimes" release. Right now, people are desperately looking for a "good" ICS image - read Pandaboard groups if you are not convinced -, and ICS won't change that much during the year. Perhaps there will be a 4.1 but when you are doing a commercial product, you don't need the latest of the latest and you certainly don't want to change your build process every month. If there was a "good" ICS release today, I think that it would be a major blockbuster for a lot of companies following Linaro. I'm mentioning the Android example because it's what people want today, but tomorrow it might be Meego or whatever. I'm not saying to stick to Google schedule, it's just an example of what is trendy today and would deserve long-term stable bits. To go one step beyond in my thinking, I'm not advocating for a new separate *strict* longer schedule. The idea might be more to have *A* milestone release from time-to-time, after something major is out (Android release, new ARM cortex), and Linaro decides that this next monthly release should be a major one, very polished, very stable and it's properly supported and advertised with clear wiki and updates for security or critical problems. The point of my email was not to criticize the very interesting work of Linaro but to give an external point of view. Let me know if Linaro has already done some thoughts about this topic, and if such discussion can occur formally or informally at the coming Connect event. Best regards, Grégoire Gentil Founder Always Innovating http://www.alwaysinnovating.com On Mon, 2012-01-23 at 18:28 +0100, Marcin Juszkiewicz wrote: > Hi > > I am arriving on Saturday evening and wondered what to do on Sunday. > Usually I spent time going to shops to buy some electronics but this > time I think that will leave it for Amazon instead. > > That leaves me Sunday for sightseeing. According to Google Maps trip to > Golden Gate bridge takes 2.5h by public transport or 40 minutes by car. > But looks like there is no car rental in hotel ;( > > Is anyone interested in going for some tour? I think that San Francisco > has some nice places to view.

12 years, 11 months

[ACTIVITY] Multimedia WG - weekly status for wk03.2012 (20120116-20120120)

by Ilias Biris

Hello please find below the summary of the status report for wk03.2012. The full report with details is in https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Latest weekly meeting notes: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2012-01-17 = Highlights = - 12.01 release. Some statistics: + started with 16 Blueprints. Due to splitting the total number of blueprints became 20 out of which: + Completed: 3 blueprints + In good progress - may finalise in 12.01: 5 blueprints + Rescheduled for 12.02: 6 blueprints + Moved back to backlog: 5 blueprints + Finally 1 Blueprint remains to be determined if it will go to backlog or 12.02 Also worked on 1 extra technical debt blueprint (CMA Debug) The development was plagued by lots of issues (see below), which resulted in a lot of work in progress (team moving about trying to find how to best proceed). Despite the statistics, the cycle was a success since many of the issues were unearthed and pushed for fixing, hopefully improving the chances for good future releases. - Lots of troubleshooting for audio issues - Completed CMA debug blueprint - technical debt from 11.12. One of the issues there was that the CMA lava test is too long to run (> 3 hours), which means short time to fix any issue (only 2-3 attempts are possible each day) - libjpeg-turbo: pulled in qualcomm 565 and 8888 updates, improved skia_bench time by 100%, pushed to git, integrated in linaro Android builds, knocked off open ubuntu libjpeg8 bugs, update pushed and in archive, put together draft lava testcase for tjunittest - For DRM : dri2video cleanup and patches - Continued tinyalsa/tinyhardware work for UCM - Continued e2eaudiotest - wrote tinyalsa based testfreq - Libav AAC decoder optimisation in progress, NEON code reviews for Libav and x264 = Issues = - Bugs + #893402 is still an issue for end-to-end audio testing, it mostly works with the right configuration but there should configuration fixed on the rootfs and also there are cases where bus exceptions can appear (see bug commentary) + #911860 Android NEON detection is busticated - Triaged + #912035 - Android: skia-bench segvs - Fix Committed + #898395 - jpegint.h missing in -dev package - Fix Committed + #889844 - Audio on HDMI is not working on trackin-panda - Fix Released from Landing Team + #908957 - ICS: All arches: No aplay / arecord or equivalent + #880173 - Audio does not work on Upstream Panda - Other issues + skia_bench timers inconsistent, it is difficult to evaluate performance improvement + Remaining Realvideo work on hold pending completion of upstream changes to decoder + LAVA: what is the best way to verify testcases? 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

12 years, 11 months

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev January 2012