linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Laura Czajkowski

Hi I've involved in organising a conference to take place on October 6th & 7th this year in Limerick Ireland. It's a technical conference speaking to students, lecturers and businesses involved in open source. The event is SkyCon which is the Skynet computer society 20th birthday. It's a 2 day conference and previous ones have been a success skycon.skynet.ie if you're interested in speaking can you send me a mail off list please and we can discuss it further. You would need to be at the event for both days, and we would cover flights and accommodation for the event for you, ideally if you're in the EU it would also be easier. Thanks Laura

14 years

checksum file for LEB images

by Akira Tsukamoto

Hi, Currently Linaro is not providing checksum file for LEB images. For example, http://releases.linaro.org/12.03/android/leb-panda/ has MD5SUM files but it contains value for only boot.tar.bz2, system.tar.bz2 and userdata.tar.bz2. There is no equivalent for the most important file which is LEB image: panda-ics-gcc46-tilt-tracking-blob.img.gz It would be more user friendly if we have md5 or sha1 checksum file for LEB image since not all people have good Internet connection and would likely to check integrity of large downloaded file after taking very long time. My preference of the name convention of the checksum file is: panda-ics-gcc46-tilt-tracking-blob.img.gz <- original binary image panda-ics-gcc46-tilt-tracking-blob.img.gz.md5sum <- md5sum hash file Regards, Akira

14 years

Possible issues with going from OMAP4 to OMAP5 with Linux

by Martin Ertsås

Hi. We are currently working towards deploying on a OMAP4460 SoC, and are using the kernel from the TI landing team in tilt-3.3, but would be willing to go to 4.4 if necessary. We are currently discussing using the OMAP5432 instead of the OMAP4460, and are wondering which issues we might encounter with doing this? Do you expect every module on the 5432 to be working well when the chip is released, or in about a year from now? I got some documentation, which basically told us to design for 4460 now, and when 5432 comes out, most of the work was already done. This was for Android though, and I'm wondering if you expect this to be the case also on Linux? Best regards Martin Ertssas

14 years

[ACTIVITY] (Deepak Saxena) April 8 - 14

by Deepak Saxena

== Deepak Saxena <dsaxena> == === Highlights === * Completed reviews! * Worked with Kiko on Android Upstreaming patch tracking. Still have mixed feelings about whether every single patch needs to be tracked to help stay on top of deliverables but will give it a try, might get some ideas on different ways to do it. (http://goo.gl/QtPwS) * Started work on new roadmap cards, closing out existing cards * Worked on Upstreaming 101 slides (http://goo.gl/QtPwS) === Plans === * Hopefully close out on training deliverables from KWG for Hong Kong Connect * Work more on Upstreaming 101 slides * Continue to dig into patch tracking * Continue work on new roadmap cards * Dig out my timex.h patches if I have time === Issues === === Travel/Time Off === * Possibly out Monday, April 30th. * Off May 4th and following week, back to work on Monday the 13th. Will have no interwebs and limited phone access. * Connect Q2, possibly with follow up travel to Linux Con Japan the week before and trip to Austin to sync up with Mounir before.

14 years

Preliminary 12.04 linux-linaro kernel tree

by Andrey Konovalov

Greetings, I've pushed the current linux-linaro tree to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch. This is still work in progress, and it misses few topics. But due to limited access to hardware at the moment it would be good to try it sooner than later on vexpress and origen at least. (I have only panda on hand). Minimal boot test has been passed on the panda, though I had to disable CPUFREQ for the board to boot (haven't looked deeper yet). Not included are the following topics present in the 12.03 release: * tracking-linaro_cpuidle: there are conflicts when rebasing it to v3.4-rc3. The topic owner has been notified, and should tell me how to proceed. * tracking-umm-3.3-wip: this one seems to be in v3.4-rc3 mainline tree, correct? * tracking-linaro-android-3.4: I've tried it with a smaller subset of the topics (w/o LT's ones), and it merged ok, but there are some conflicts with the LT's stuff as it seems. Will have a deeper look tomorrow. No action from John is required at the moment. Here is the list of the topic included into this tree currently: # integration <name> <base> <topic1> <topic2> ... <topicN> # - the merge order is <topic1> to <topicN>. integration linux-linaro v3.4-rc3 ufs emmc thermal_exynos4_imx6 linaro-configs-3.4 armlt-hdlcd armlt-mmc armlt-arm-arch-fixes armlt-misc-fixes armlt-ubuntu-config armlt-android-config armlt-gator samslt-base samslt-core samslt-bl samslt-dt samslt-fb samslt-pd samslt-rtc samslt-s2ram samslt-asv_cpufreq thermal_exynos4_imx6 samslt-led samslt-dummy_reg samslt-gadget samslt-touch samslt-wlan samslt-audio samslt-hdmi samslt-mali samslt-cma_v24 unsorted Where the topics are: # topic <local branch> <remote/branch> <topic base> # - <base> must be another topic # Example1: tracking-armlt-gator lt_arm/tracking-armlt-gator # - missing <topic base> here assumes the mainline Linus tree. # # ARM LT topics: topic armlt-hdlcd lt_arm/tracking-armlt-hdlcd topic armlt-mmc lt_arm/tracking-armlt-mmc topic armlt-arm-arch-fixes lt_arm/tracking-armlt-arm-arch-fixes topic armlt-misc-fixes lt_arm/tracking-armlt-misc-fixes topic armlt-ubuntu-config lt_arm/tracking-armlt-ubuntu-config topic armlt-android-config lt_arm/tracking-armlt-android-config topic armlt-gator lt_arm/tracking-armlt-gator # topic ufs svenkatr/ufs-for-linux-linaro topic emmc svenkatr/emmc-for-linux-linaro topic thermal_exynos4_imx6 amitdanielk/thermal_exynos4_imx6_work topic unsorted ynk/tracking-orphan-unsorted # Samsung LT topics: topic samslt-base lt_samsung/topic/base topic samslt-asv_cpufreq lt_samsung/topic/asv_cpufreq samslt-base topic samslt-audio lt_samsung/topic/audio samslt-base topic samslt-bl lt_samsung/topic/bl samslt-base topic samslt-cma_v24 lt_samsung/topic/cma_v24 samslt-base topic samslt-core lt_samsung/topic/core samslt-base topic samslt-dt lt_samsung/topic/dt samslt-base topic samslt-dummy_reg lt_samsung/topic/dummy_reg samslt-base topic samslt-fb lt_samsung/topic/fb samslt-base topic samslt-gadget lt_samsung/topic/gadget samslt-base topic samslt-hdmi lt_samsung/topic/hdmi samslt-base topic samslt-led lt_samsung/topic/led samslt-base topic samslt-mali lt_samsung/topic/mali samslt-base topic samslt-pd lt_samsung/topic/pd samslt-base topic samslt-rtc lt_samsung/topic/rtc samslt-base topic samslt-s2ram lt_samsung/topic/s2ram samslt-base topic samslt-touch lt_samsung/topic/touch samslt-base topic samslt-wlan lt_samsung/topic/wlan samslt-base And the remotes are: # # remote <remote name> <remote URL> # remote lt_arm git://git.linaro.org/landing-teams/working/arm/kernel.git remote pmg_rob_lee git://git.linaro.org/people/rob_lee/linux.git remote svenkatr git://github.com/svenkatr/linux.git remote amitdanielk git://git.linaro.org/people/amitdanielk/linux.git remote android_jstultz git://git.linaro.org/people/jstultz/android.git remote ynk git://git.linaro.org/people/ynk/linux-linaro-tracking.git remote upstream git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git remote lt_samsung git://git.linaro.org/landing-teams/working/samsung/kernel.git Thanks, Andrey

14 years

[PATCH v2] iommu: OMAP: device detach on domain destroy

by Omar Ramirez Luna

'domain_destroy with devices attached' case isn't yet handled, instead code assumes that the device was already detached. If the domain is destroyed the hardware still has access to invalid pointers to its page table and internal iommu object. In order to detach the users we need to track devices using the iommu, current use cases only have one user of iommu per instance. When required this can evolve to a list with the devices using the iommu_dev. Reported-by: Joerg Roedel <joro(a)8bytes.org> Reviewed-by: Ohad Ben-Cohen <ohad(a)wizery.com> Signed-off-by: Omar Ramirez Luna <omar.luna(a)linaro.org> --- v2: rebased onto v3.4-rc2 drivers/iommu/omap-iommu.c | 32 +++++++++++++++++++++++--------- 1 files changed, 23 insertions(+), 9 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 6899dcd..e70ee2b 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -41,11 +41,13 @@ * @pgtable: the page table * @iommu_dev: an omap iommu device attached to this domain. only a single * iommu device can be attached for now. + * @dev: Device using this domain. * @lock: domain lock, should be taken when attaching/detaching */ struct omap_iommu_domain { u32 *pgtable; struct omap_iommu *iommu_dev; + struct device *dev; spinlock_t lock; }; @@ -1081,6 +1083,7 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct device *dev) } omap_domain->iommu_dev = arch_data->iommu_dev = oiommu; + omap_domain->dev = dev; oiommu->domain = domain; out: @@ -1088,19 +1091,16 @@ out: return ret; } -static void omap_iommu_detach_dev(struct iommu_domain *domain, - struct device *dev) +static void _omap_iommu_detach_dev(struct omap_iommu_domain *omap_domain, + struct device *dev) { - struct omap_iommu_domain *omap_domain = domain->priv; - struct omap_iommu_arch_data *arch_data = dev->archdata.iommu; struct omap_iommu *oiommu = dev_to_omap_iommu(dev); - - spin_lock(&omap_domain->lock); + struct omap_iommu_arch_data *arch_data = dev->archdata.iommu; /* only a single device is supported per domain for now */ if (omap_domain->iommu_dev != oiommu) { dev_err(dev, "invalid iommu device\n"); - goto out; + return; } iopgtable_clear_entry_all(oiommu); @@ -1108,8 +1108,16 @@ static void omap_iommu_detach_dev(struct iommu_domain *domain, omap_iommu_detach(oiommu); omap_domain->iommu_dev = arch_data->iommu_dev = NULL; + omap_domain->dev = NULL; +} -out: +static void omap_iommu_detach_dev(struct iommu_domain *domain, + struct device *dev) +{ + struct omap_iommu_domain *omap_domain = domain->priv; + + spin_lock(&omap_domain->lock); + _omap_iommu_detach_dev(omap_domain, dev); spin_unlock(&omap_domain->lock); } @@ -1148,13 +1156,19 @@ out: return -ENOMEM; } -/* assume device was already detached */ static void omap_iommu_domain_destroy(struct iommu_domain *domain) { struct omap_iommu_domain *omap_domain = domain->priv; domain->priv = NULL; + /* + * An iommu device is still attached + * (currently, only one device can be attached) ? + */ + if (omap_domain->iommu_dev) + _omap_iommu_detach_dev(omap_domain, omap_domain->dev); + kfree(omap_domain->pgtable); kfree(omap_domain); } -- 1.7.4.1

14 years

[PATCH] prctl.2, proc.5: proposal to reflect http://lwn.net/Articles/484162

by Dmitry Antipov

Document PR_GET_TIMERSLACK and PR_SET_TIMERSLACK for prctl (2). Document /proc/sys/kernel/timer_slack for proc (5). Signed-off-by: Dmitry Antipov <dmitry.antipov(a)linaro.org> --- man2/prctl.2 | 15 +++++++++++++++ man5/proc.5 | 4 ++++ 2 files changed, 19 insertions(+), 0 deletions(-) diff --git a/man2/prctl.2 b/man2/prctl.2 index effad2a..dcf803f 100644 --- a/man2/prctl.2 +++ b/man2/prctl.2 @@ -378,6 +378,21 @@ Return the current per-process machine check kill policy. All unused .BR prctl () arguments must be zero. +.TP +.BR PR_GET_TIMERSLACK " (since Linux 2.6.28)" +Return the current per-thread high-resolution timers slack, in nanoseconds. +.TP +.BR PR_SET_TIMERSLACK " (since Linux 2.6.28)" +Set the current per-thread high-resolution timers slack. If arg2 is less than or +equal to zero, system-wide default value is restored. The system-wide default can +be read and set by /proc/sys/kernel/timer_slack (see +.BR proc (5)). +Otherwise, if arg2 is less than or equal to HRTIMER_MAX_SLACK (which is a kernel +constant defined in include/linux/hrtimer.h), this value is set up as a new slack. +Slack is not inherited across +.BR fork (2); +new process initially uses system-wide default slack, and new thread inherits +it's slack from the group leader. .SH "RETURN VALUE" On success, .BR PR_GET_DUMPABLE , diff --git a/man5/proc.5 b/man5/proc.5 index 54ccdd8..0493b6b 100644 --- a/man5/proc.5 +++ b/man5/proc.5 @@ -2407,6 +2407,10 @@ date behind it indicates the time the kernel was built. This file specifies the system-wide limit on the number of threads (tasks) that can be created on the system. .TP +.IR /proc/sys/kernel/timer_slack +This file specifies the system-wide default slack for +high-resolution timers, in nanoseconds. +.TP .IR /proc/sys/kernel/zero-paged " (PowerPC only) " This file contains a flag. -- 1.7.7.6

14 years

3.3 kernel from TI landing teams and powervr problems.

by Martin Ertsås

Hi. I am not 100% sure this is the correct place to ask, but since I know at least Ricardo Salveti are working on these drivers for omap4, and I haven't heard anything from the ppa's mailing list, I try to ask here. If this was completely wrong I'm sorry, but would still appreciate a hint as to where to ask and who to contact. We are compiling what is now HEAD in the tilt-3.3 branch from the TI landing team. To compile the module needed for the powervr drivers, we had to get the pvr-omap4-dkms-1.7.15 and pvr-omap4-1.7.15 from http://ppa.launchpad.net/tiomap-dev/omap-trunk/ubuntu/pool/main/p/ We downloaded the tar.gz from those, extracted them and compiled them. Problem starts when we boot the board and try to run startx. The xorg config which comes with the later package is loaded, but when trying to start X I get the error: (EE) Failed to load /usr/lib/xorg/modules/drivers/pvr_drv.so: /usr/lib/xorg/modules/drivers/pvr_drv.so: undefined symbol: OMAPFinishAccess None of the libraries in pvr-omap4 contains this symbol, so I'm wondering if I'm doing something wrong, or if there is something wrong with the binary? When comparing to the library from rsalveti, from people/rsalveti/pvr-omap4.git, I see that the dynsym table contains 232 entries, but there are only 64 entries in the same table in the other library. Is this correct, or should there be more entries in the 1.7.15 library? Both the Xorg log and the readelf output from both libraries are attached, if you have questions/need more info, please do not hesitate to ask. Thank you in advance for the help, and thank you for the great work you put in for making embedded Linux better. Best regards Martin Ertsaas

14 years

[PATCH] iommu: OMAP: device detach on domain destroy

by Omar Ramirez Luna

'domain_destroy with devices attached' case isn't yet handled, instead code assumes that the device was already detached. If the domain is destroyed the hardware still has access to invalid pointers to its page table and internal iommu object. In order to detach the users we need to track devices using the iommu, current use cases only have one user of iommu per instance. When required this can evolve to a list with the devices using the iommu_dev. Reported-by: Joerg Roedel <joro(a)8bytes.org> Reviewed-by: Ohad Ben-Cohen <ohad(a)wizery.com> Signed-off-by: Omar Ramirez Luna <omar.luna(a)linaro.org> --- drivers/iommu/omap-iommu.c | 32 +++++++++++++++++++++++--------- 1 files changed, 23 insertions(+), 9 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 821062a..e32bd15 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -41,11 +41,13 @@ * @pgtable: the page table * @iommu_dev: an omap iommu device attached to this domain. only a single * iommu device can be attached for now. + * @dev: Device using this domain. * @lock: domain lock, should be taken when attaching/detaching */ struct omap_iommu_domain { u32 *pgtable; struct omap_iommu *iommu_dev; + struct device *dev; spinlock_t lock; }; @@ -1074,6 +1076,7 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct device *dev) } omap_domain->iommu_dev = arch_data->iommu_dev = oiommu; + omap_domain->dev = dev; oiommu->domain = domain; /* temporary workaround */ @@ -1084,19 +1087,16 @@ out: return ret; } -static void omap_iommu_detach_dev(struct iommu_domain *domain, - struct device *dev) +static void _omap_iommu_detach_dev(struct omap_iommu_domain *omap_domain, + struct device *dev) { - struct omap_iommu_domain *omap_domain = domain->priv; - struct omap_iommu_arch_data *arch_data = dev->archdata.iommu; struct omap_iommu *oiommu = dev_to_omap_iommu(dev); - - spin_lock(&omap_domain->lock); + struct omap_iommu_arch_data *arch_data = dev->archdata.iommu; /* only a single device is supported per domain for now */ if (omap_domain->iommu_dev != oiommu) { dev_err(dev, "invalid iommu device\n"); - goto out; + return; } iopgtable_clear_entry_all(oiommu); @@ -1104,11 +1104,19 @@ static void omap_iommu_detach_dev(struct iommu_domain *domain, omap_iommu_detach(oiommu); omap_domain->iommu_dev = arch_data->iommu_dev = NULL; + omap_domain->dev = NULL; /* temporary workaround */ clk_disable(oiommu->clk); +} -out: +static void omap_iommu_detach_dev(struct iommu_domain *domain, + struct device *dev) +{ + struct omap_iommu_domain *omap_domain = domain->priv; + + spin_lock(&omap_domain->lock); + _omap_iommu_detach_dev(omap_domain, dev); spin_unlock(&omap_domain->lock); } @@ -1147,13 +1155,19 @@ out: return -ENOMEM; } -/* assume device was already detached */ static void omap_iommu_domain_destroy(struct iommu_domain *domain) { struct omap_iommu_domain *omap_domain = domain->priv; domain->priv = NULL; + /* + * An iommu device is still attached + * (currently, only one device can be attached) ? + */ + if (omap_domain->iommu_dev) + _omap_iommu_detach_dev(omap_domain, omap_domain->dev); + kfree(omap_domain->pgtable); kfree(omap_domain); } -- 1.7.4.1

14 years

[PATCH 0/4] OMAP thermal fixes

by Eduardo Valentin

Hello guys, Here are a couple of fixes and clean ups on the omap thermal code. These are trivial I'd say. There is one question about the location of the BG sensor code. Looking to the existing code under drivers/thermal/, looks like it is practice to keep the sensor driver code there as well. So, I was wondering if same needs to be done for OMAP code, because as of today the sensor code is residing under drivers/mfd. I will cook something and send it across to see how it looks like. Eduardo Valentin (4): thermal: omap: fix get mode function MFD: omap scm: remove all references to TI THERMAL_FRAMEWORK config MFD: omap temp sensor: rework initialization sequence omap thermal: fix off by one issue drivers/mfd/omap4460plus_temp_sensor.c | 272 +++++++++----------------------- drivers/mfd/omap4plus_scm.c | 9 - drivers/thermal/omap_thermal.c | 14 +- include/linux/mfd/omap4_scm.h | 4 +- 4 files changed, 80 insertions(+), 219 deletions(-) -- 1.7.7.1.488.ge8e1c

14 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev