Re: [ANNOUNCE] New boot loader on Snowball
On Mon, May 14, 2012 at 5:24 PM, Mathieu Poirier wrote: > All, > > In our ongoing effort to move to an upstream-supported code base and > booting the snowball with a device tree (DT) I have change the boot > loader in the following android builds [1][2][3] to u-boot-linaro-stable > [4]. > > Once the linaro-uboot is installed in a system it won't be able to boot > images that were created at an earlier time. > > Say that build #500 has the new linaro-uboot and the image has been > installed on the emmc. Once powered this uboot will not be able to > boot build #499 that is installed on the mmc. To fix the problem, > simply install build #500 on the mmc. This is because the mmc commands > in the IK-uboot and the linaro-uboot differ. > > To install the linaro-uboot you *must* use the latest > android-linaro-media-create found here [5] until the changes get merged > in the official repository [6]. > > Something like: > > $ bzr branch lp:~mathieu.poirier/linaro-image-tools/linaro-image-tools > > Last but not least, the linaro-uboot is currently not able to save the > environment variable block to the emmc card. That work is ongoing and > the functionality expected to be part of 12.05. That's awesome, great work together with John! Did you have any issue on the kernel/userspace side with the new boot loader? Would be nice to test the ethernet support as well, so we could start supporting PXE booting :-) Thanks! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Golly, is that the dual SD card you and David from tincantools have been working on?
On Mon, May 14, 2012, Zach Pfeffer wrote: > https://plus.google.com/u/0/104422661029399872488/posts/3KpdBSzW4FK awesome!! how expensive is it to build in the end? Will we build some for LAVA folks to play with? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Golly, is that the dual SD card you and David from tincantools have been working on?
On 15 May 2012 12:38, Loïc Minier wrote: > On Mon, May 14, 2012, Zach Pfeffer wrote: >> https://plus.google.com/u/0/104422661029399872488/posts/3KpdBSzW4FK > > awesome!! how expensive is it to build in the end? Will we build some > for LAVA folks to play with? It sounds very nice and useful - but what is it and why is this so exciting :) ? Ramana > > -- > Loïc Minier > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Golly, is that the dual SD card you and David from tincantools have been working on?
On Tue, May 15, 2012 at 1:44 PM, Ramana Radhakrishnan wrote: > On 15 May 2012 12:38, Loïc Minier wrote: >> On Mon, May 14, 2012, Zach Pfeffer wrote: >>> https://plus.google.com/u/0/104422661029399872488/posts/3KpdBSzW4FK >> >> awesome!! how expensive is it to build in the end? Will we build some >> for LAVA folks to play with? > > It sounds very nice and useful - but what is it and why is this so > exciting :) ? > I gave a bit background as a comment to my post: - https://plus.google.com/u/0/117775935412882278033/posts/8JTBhQSkUdS " Basically a gadget that allows you to use one sd card shared by two computers. Power off computer A and computer B will see the sdcard. Power on computer A and sd card will get unplugged from computer B; computer A can use it exclusively until it gets powered off again. ... In short: good stuff ... " -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Golly, is that the dual SD card you and David from tincantools have been working on?
On 15 May 2012 12:54, Alexander Sack wrote: > On Tue, May 15, 2012 at 1:44 PM, Ramana Radhakrishnan > wrote: >> On 15 May 2012 12:38, Loïc Minier wrote: >>> On Mon, May 14, 2012, Zach Pfeffer wrote: https://plus.google.com/u/0/104422661029399872488/posts/3KpdBSzW4FK >>> >>> awesome!! how expensive is it to build in the end? Will we build some >>> for LAVA folks to play with? >> >> It sounds very nice and useful - but what is it and why is this so >> exciting :) ? >> > > I gave a bit background as a comment to my post: > - https://plus.google.com/u/0/117775935412882278033/posts/8JTBhQSkUdS Thanks for the explanation - it would be nice if such a comment were in the original post on linaro-dev rather than a one line comment with no explanation anywhere for mere mortals :) > > " > Basically a gadget that allows you to use one sd card shared by two computers. > > Power off computer A and computer B will see the sdcard. Power on > computer A and sd card will get unplugged from computer B; computer A > can use it exclusively until it gets powered off again. (Assuming that computer B is powered off at the same time that Computer A comes on) Interesting though I'm not sure where I'd use it and how it would work if I had a running computer B and it was using that device :) > > ... > > In short: good stuff ... It might well be, but it's hard to understand with cryptic juxtaposition of terms :-/ "Dual SD Card" really doesn't convey that meaning !! Ramana > " > > > > -- > Alexander Sack > Technical Director, Linaro Platform Teams > http://www.linaro.org | Open source software for ARM SoCs > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Golly, is that the dual SD card you and David from tincantools have been working on?
On 15 May 2012, at 13:05, Ramana Radhakrishnan wrote: > On 15 May 2012 12:54, Alexander Sack wrote: >> On Tue, May 15, 2012 at 1:44 PM, Ramana Radhakrishnan >> wrote: >>> On 15 May 2012 12:38, Loïc Minier wrote: On Mon, May 14, 2012, Zach Pfeffer wrote: > https://plus.google.com/u/0/104422661029399872488/posts/3KpdBSzW4FK awesome!! how expensive is it to build in the end? Will we build some for LAVA folks to play with? >>> >>> It sounds very nice and useful - but what is it and why is this so >>> exciting :) ? >>> >> >> I gave a bit background as a comment to my post: >> - https://plus.google.com/u/0/117775935412882278033/posts/8JTBhQSkUdS > > Thanks for the explanation - it would be nice if such a comment were > in the original post on linaro-dev rather than a one line comment with > no explanation anywhere for mere mortals :) > >> >> " >> Basically a gadget that allows you to use one sd card shared by two >> computers. >> >> Power off computer A and computer B will see the sdcard. Power on >> computer A and sd card will get unplugged from computer B; computer A >> can use it exclusively until it gets powered off again. > > (Assuming that computer B is powered off at the same time that > Computer A comes on) Interesting though I'm not sure where I'd use it > and how it would work if I had a running computer B and it was using > that device : It's essentially being developed for LAVA so that we can test a complete image, including u-boot (or uefi or whatever) as well as the boot and rootfs alone. Thanks Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Golly, is that the dual SD card you and David from tincantools have been working on?
On 15 May 2012 13:05, Ramana Radhakrishnan wrote: > On 15 May 2012 12:54, Alexander Sack wrote: >> Basically a gadget that allows you to use one sd card shared by two >> computers. >> >> Power off computer A and computer B will see the sdcard. Power on >> computer A and sd card will get unplugged from computer B; computer A >> can use it exclusively until it gets powered off again. > > (Assuming that computer B is powered off at the same time that > Computer A comes on) Interesting though I'm not sure where I'd use it > and how it would work if I had a running computer B and it was using > that device :) No, computer B can remain powered on all the time. Imagine computer A being a Pandaboard with power controlled by computer B, a PC. Now the PC can power off the Pandaboard, write an image to the card, and power on the Panda again. This allows fully automatic recovery from a bad boot loader/kernel. -- Mans Rullgard / mru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] New boot loader on Snowball
On 12-05-15 01:04 AM, Ricardo Salveti wrote: > On Mon, May 14, 2012 at 5:24 PM, Mathieu Poirier > wrote: >> All, >> >> In our ongoing effort to move to an upstream-supported code base and >> booting the snowball with a device tree (DT) I have change the boot >> loader in the following android builds [1][2][3] to u-boot-linaro-stable >> [4]. >> >> Once the linaro-uboot is installed in a system it won't be able to boot >> images that were created at an earlier time. >> >> Say that build #500 has the new linaro-uboot and the image has been >> installed on the emmc. Once powered this uboot will not be able to >> boot build #499 that is installed on the mmc. To fix the problem, >> simply install build #500 on the mmc. This is because the mmc commands >> in the IK-uboot and the linaro-uboot differ. >> >> To install the linaro-uboot you *must* use the latest >> android-linaro-media-create found here [5] until the changes get merged >> in the official repository [6]. >> >> Something like: >> >> $ bzr branch lp:~mathieu.poirier/linaro-image-tools/linaro-image-tools >> >> Last but not least, the linaro-uboot is currently not able to save the >> environment variable block to the emmc card. That work is ongoing and >> the functionality expected to be part of 12.05. > > That's awesome, great work together with John! > > Did you have any issue on the kernel/userspace side with the new boot > loader? Would be nice to test the ethernet support as well, so we > could start supporting PXE booting :-) > > Thanks! I have not faced any issues other than having to lower the DT address in memory - Linux and Anddroid came up properly from thereon. I must specify that we currently don't boot using a DT. Regards, Mathieu. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC PATCH v1] AudiVal (Audio Validation Suite for Linux)
AudiVal (Audio Validation Suite for Linux)
This is an attempt to automate and integrate various audio related tests which
can help validate audio on various boards supported by Linaro. Motivation for
this project comes from various audio tests listed at:
https://wiki.linaro.org/TomGall/LinaroAudioFeatureIndex
The git repo for this project can be cloned from:
git://git.linaro.org/people/harshbora/audival.git
Various files required by this script are available in the git repo.
Requesting all to test this script on various boards that you may have access
to and share feedback to make it better.
TODO: Add tests for Audio over USB, Bluetooth.
Signed-off-by: Harsh Prateek Bora
diff --git a/AudiVal.py b/AudiVal.py
new file mode 100755
index 000..7d56c4e
--- /dev/null
+++ b/AudiVal.py
@@ -0,0 +1,247 @@
+#!/usr/bin/env python
+#
+# Audival : Audio Validation Suite for Linux.
+#
+# Author: Harsh Prateek Bora
+#
+#
+
+import os
+import sys
+import getopt
+from subprocess import * # for calling external programs
+import commands # deprecated since python 2.6, Python 3.0 uses subprocess
+
+def usage():
+print "="
+print "AudiVal: Audio Validation Suite for Linux"
+print "="
+print "Usage:"
+print sys.argv[0], "[--check-info]"
+print
+print "Supported HW: PandaBoard (ES), BeagleBoard (XM), i.MX53, i.MX6,
Origen, Snowball"
+sys.exit(1)
+
+SpeakerJack = {
+'GenuineIntel': 'Analog',
+'Panda':'Headset',
+'Beagle': 'TWL4030',
+'i.MX53': 'HiFi',
+'i.MX6':'HiFi',
+'ORIGEN': 'Pri_Dai',
+'Snowball': 'Headset'
+}
+
+MicJack = {
+'GenuineIntel': 'Analog',
+'Panda':'Headset', # not sure though, arecord doesnt work for
me!
+'Beagle': 'TWL4030',
+'i.MX53': 'HiFi',
+'i.MX6':'HiFi',
+'ORIGEN': 'Pri_Dai',
+'Snowball': 'Headset'
+}
+
+# As and when HDMI out/in device string differs, we'll need 2 dictionaries.
+HDMI_Audio = {
+'GenuineIntel': 'HDMI',
+'Panda':'HDMI',
+'Beagle': 'HDMI',
+'i.MX53': 'HDMI',
+'i.MX6':'HDMI', # audio out only supported, audio in not
supported.
+'ORIGEN': 'HDMI',
+'Snowball': 'hdmi' # odd one, lowercase
+}
+
+Audio_Devices = {
+'playback':'aplay-l.log',
+'capture': 'arecord-l.log'
+}
+
+def get_device_list(logfile):
+fobj = open(logfile)
+return fobj
+
+def get_card_device_info_by_name(devicestr, fobj):
+"""Helper routine to get card, device number by interface name"""
+optxt = fobj.readlines()
+card = ""
+device = ""
+for line in optxt:
+if devicestr in line:
+cardtext, colon, text = line.partition(':')
+pre, sep, card = cardtext.partition(' ')
+devtext, colon, text = text.partition(':')
+pre, sep, device = devtext.partition('device ')
+break
+hwstr = 'plughw:' + card + ',' + device
+if card is "" and device is "":
+return None
+return hwstr
+
+def speaker_test_audio_jack(board):
+fobj = get_device_list(Audio_Devices['playback'])
+print "speaker-test over audio jack .."
+headset_jack_id = get_card_device_info_by_name(SpeakerJack[board], fobj)
+fobj.close()
+if headset_jack_id is None:
+print "No Audio Jack found !"
+return
+call("date > speaker-test-jack.log", shell=True)
+cmdstr = "speaker-test -D " + headset_jack_id + " -t s -c 2 -l 1 >
speaker-test-jack.log 2>&1"
+call(cmdstr, shell=True)
+print "If you heard beeps from left and right speaker, test passed."
+
+def aplay_over_jack(board):
+fobj = get_device_list(Audio_Devices['playback'])
+headset_jack_id = get_card_device_info_by_name(SpeakerJack[board], fobj)
+print "Testing aplay over audio jack .."
+fobj.close()
+if headset_jack_id is None:
+print "No Audio Jack found !"
+return
+cmdstr = "aplay login.wav -D " + headset_jack_id
+call(cmdstr, shell=True)
+print "If you heard a stereo sound, test passed."
+# Check dmesg to see if there is an error or I2C error
+call("dmesg | tail | grep error", shell=True)
+print "Note: Error, if any, shall be displayed above."
+
+def arecord_and_aplay_over_audio_jack(board):
+# Record the WAV stream and play it back.
+fobj = get_device_list(Audio_Devices['capture'])
+mic_jack_id = get_card_device_info_by_name(MicJack[board], fobj)
+if mic_jack_id is None:
+print "No Mic Jack found !"
+return
+cmdstr = "arecord -c 2 -f S16_LE -d 10 -r 44100 aud44k16S.wav -D " +
mic_jack_id
+print "Testing arecord over audio jack .."
+print "Started recording audio over jack for 10 seconds (replay follows)
.."
+call(cmdstr, sh
Re: Standardized kernel interface for 2D blitters
On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: > I've previously read (probably on Phoronix) that Linaro is working out > a 'standard' kernel interface for 2D blitters IPs as commonly found on > SoCs. > > Has it ever been the case? If yes, are there any > documentation/references online? I wonder if you are talking about dma-buf and the other collection of work around Unified Memory Management: https://wiki.linaro.org/OfficeofCTO/MemoryManagement It's not really specific for 2D blitter IPs, but it does define how memory can be allocated and shared between different devices, particularly between the CPU, display controller and GPU IP. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 15 May 2012 08:17, Andy Green wrote: > On 15/05/12 07:03, Somebody in the thread at some point said: > >>> While migrating the Android solution to use linux-linaro-core-tracking, I >>> get kernel panic with umm-patchset (haven't dug deep into it though, it >>> might be because the multimedia drivers are not yet migrated for using >>> UMM). >>> Would it be ok if we only include CMA patchset, but not the dma-buf and >>> dma-mapping patches? >>> >> >> are you asking whether we would consider to drop dma-mapping from >> linux-linaro tree or if it would be a bad idea to do that in your >> samsung LT tree? > > > We will need latest dmabuf and associated stuff. > > >> For linux-linaro, we probably would prefer to try to fix it before >> talking about the option to drop such a core topic. Do you have more >> info about the kernel panic you see? The issue is something that we are somewhat aware of, as we had similar issue when we had tried to migrate our multimedia solution to use dma-buf/dma-mapping. > > > Yes approach of dropping -core topics to manage problems isn't really > workable. Even if you did it Tushar's older stuff will conflict when you > try to unify the kernels. > > If it's the case that stuff in linaro tree is more upstream-converged than > what Tushar's tree works with, then we can put it another way: the current > implementation in Samsung tree (no ding intended since it can just as easily > be any of us and no doubt soon will be) needs to be fixed to work with > current upstream-headed pieces it needs. > Yes, indeed. We are working on fixing this stuff. Just that, it won't be fixed before 2012.05 release. That is why I was wondering whether Samsung LT Android solution could use linux-linaro tree. > When you put it like that, it's clearer that there's value for Samsung in > fixing this in Samsung LT tree to work with latest upstream-headed series, > because they're going to have to deal with same breakage shortly from > upstream path anyway. > > I dunno if it helps, but Rob Clark has a few patches on top of current stuff > that might also be something to do with something for Tushar > > http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tracking-topic-omapdrm-dmabuf > Sure, I will have a look at them if they help. > > -Andy > > -- > Andy Green | TI Landing Team Leader > Linaro.org │ Open source software for ARM SoCs | Follow Linaro > http://facebook.com/pages/Linaro/155974581091106 - > http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 15 May 2012 04:33, Alexander Sack wrote: > Hi Tushar, > > On Mon, May 14, 2012 at 8:04 PM, Tushar Behera > wrote: >> On 14 May 2012 13:40, Tushar Behera wrote: >>> On 05/12/2012 11:09 PM, Andrey Konovalov wrote: Tushar, On 05/11/2012 09:04 AM, Tushar Behera wrote: > On 05/11/2012 01:04 AM, Andrey Konovalov wrote: >> Greetings, >> >> So far I wasn't updating the linux-linaro tree since the 12.04 release. >> (The generic topic updates were being done to the >> linux-linaro-core-tracking tree) >> >> Now it is time to move the focus to the linux-linaro tree. For one week >> it will use the mainline tip as the base. Then, on next Thursday the >> most recent -rc will be selected as the base, and won't be changed until >> 12.05 is released. Most probably it will be v3.4-rc7. >> >> The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus >> the 7 generic topics currently included into the >> linux-linaro-core-tracking tree: >> ufs (ufs-for-linux-linaro) >> emmc (emmc-for-linux-linaro) >> thermal_exynos4_imx6 (thermal_exynos4_imx6_work) >> linaro-android-3.4 >> armlt-gator (tracking-armlt-gator) >> umm-wip (umm-3.4rc4-wip) >> linaro-configs-3.4 >> If you don't see your generic topic in this list, but you think it >> should be there, please let me know ASAP. If you have a new topic to >> add, please send me the request before the next Thursday, May 17; the >> sooner, the better. The requirements for a topic can be found here: >> https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it >> >> >> >> The landing teams - please update your topic branches if needed: >> ARM: >> tracking-armlt-hdlcd tracking-armlt-mmc >> tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes >> tracking-armlt-ubuntu-config tracking-armlt-android-config >> Samsung: >> topic/base topic/core topic/bl topic/dt topic/fb topic/pd >> topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg >> topic/gadget topic/touch topic/wlan topic/audio topic/hdmi >> topic/mali topic/cma_v24 topic/android_config >> > Is any other LT using CMA patchset? If so, this topic branch can be > moved into linux-linaro-core-tracking. That's a good idea, thanks! The only problem is that your topic/cma_v24 is based on the topic/base, and thus includes "CONFIG: ORIGEN:" commits and an older version of linaro-configs-3.4 topic. In particular, the latter recreates configs/panda.conf file which has been deleted from the current linaro-configs-3.4. Could you please make topic/cma_v24 mainline based (drop these "CONFIG: ORIGEN:" and configs/* changes)? And is the "CONFIG_CMA_SIZE_MBYTES=32" option Origen specific or generic? If it is generic, it should go into a separate file, e.g. configs/cma.conf. >>> I didn't mean to include topic/cma_v24 with the patches from topic/base, >>> rather the clean patchset from Marek. But now that we have the umm topic >>> branch in linux-linaro-core-tracking, we don't need topic/cma_v24 >>> anymore. If any fixes with respect to Origen are required, I will queue >>> them up in another topic branch. >>> >>> I will shortly send you the list of topic branches for 2012.05 release, >>> now that 3.4-rc7 is already released. >>> >> >> While migrating the Android solution to use linux-linaro-core-tracking, I >> get kernel panic with umm-patchset (haven't dug deep into it though, it >> might be because the multimedia drivers are not yet migrated for using UMM). >> Would it be ok if we only include CMA patchset, but not the dma-buf and >> dma-mapping patches? >> > > are you asking whether we would consider to drop dma-mapping from > linux-linaro tree or if it would be a bad idea to do that in your > samsung LT tree? > Actually we were planning to base 2012.05 release on linux-linaro kernel, that is why I was looking at options. We will rather have 2012.05 release based Samsung LT tree till this issue has been fixed. > For linux-linaro, we probably would prefer to try to fix it before > talking about the option to drop such a core topic. Do you have more > info about the kernel panic you see? > > -- > Alexander Sack > Technical Director, Linaro Platform Teams > http://www.linaro.org | Open source software for ARM SoCs > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 15/05/12 23:01, Somebody in the thread at some point said: If it's the case that stuff in linaro tree is more upstream-converged than what Tushar's tree works with, then we can put it another way: the current implementation in Samsung tree (no ding intended since it can just as easily be any of us and no doubt soon will be) needs to be fixed to work with current upstream-headed pieces it needs. Yes, indeed. We are working on fixing this stuff. Just that, it won't be fixed before 2012.05 release. That is why I was wondering whether Samsung LT Android solution could use linux-linaro tree. Understood... for one reason and another we often can't do stuff for monthly release timescale either and have to pass on it. However in medium term, the LT trees are going to have to become compatible with llct, and it's sensible enough because llct is closer to what's going to mainline than what the LTs individually have. Otherwise there'll never be any genuine unified tree. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Perf record format portability
Hello, are there any thoughts on how much of the perf.data is portable and how much it should be? I'm interesting in recording scheduler activity on one machine and then replaying on another. As I can see, replaying x86 perf.data on ARM doesn't work. At least, should it work with a small subset of recorded events (for example, sched:sched_switch, sched:sched_process_exit, sched:sched_process_fork, sched:sched_wakeup and sched:sched_migrate_task) on the same architecture? Thanks in advance, Dmitry ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] New boot loader on Snowball
On 14 May 2012 15:24, Mathieu Poirier wrote: > All, > > In our ongoing effort to move to an upstream-supported code base and > booting the snowball with a device tree (DT) I have change the boot > loader in the following android builds [1][2][3] to u-boot-linaro-stable > [4]. > > Once the linaro-uboot is installed in a system it won't be able to boot > images that were created at an earlier time. > > Say that build #500 has the new linaro-uboot and the image has been > installed on the emmc. Once powered this uboot will not be able to > boot build #499 that is installed on the mmc. To fix the problem, > simply install build #500 on the mmc. This is because the mmc commands > in the IK-uboot and the linaro-uboot differ. Mathieu, would you sync with Fathi and get this info up on android-build? > To install the linaro-uboot you *must* use the latest > android-linaro-media-create found here [5] until the changes get merged > in the official repository [6]. > > Something like: > > $ bzr branch lp:~mathieu.poirier/linaro-image-tools/linaro-image-tools > > Last but not least, the linaro-uboot is currently not able to save the > environment variable block to the emmc card. That work is ongoing and > the functionality expected to be part of 12.05. What problem does this cause? > Find me on IRC if you have any questions. > > Regards, > Mathieu. > > [1]. > https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc47-igloo-tracking-blob > [2]. > https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc47-igloo-stable-blob > [3]. > https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc46-igloo-stable-blob > [4]. http://git.linaro.org/git/boot/u-boot-linaro-stable.git > [5]. > https://code.launchpad.net/~mathieu.poirier/linaro-image-tools/linaro-image-tools > [6]. https://code.launchpad.net/linaro-image-tools > > ___ > linaro-android mailing list > linaro-andr...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-android -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Golly, is that the dual SD card you and David from tincantools have been working on?
On 15 May 2012 13:45, Mans Rullgard wrote: > On 15 May 2012 13:05, Ramana Radhakrishnan > wrote: >> On 15 May 2012 12:54, Alexander Sack wrote: >>> Basically a gadget that allows you to use one sd card shared by two >>> computers. >>> >>> Power off computer A and computer B will see the sdcard. Power on >>> computer A and sd card will get unplugged from computer B; computer A >>> can use it exclusively until it gets powered off again. >> >> (Assuming that computer B is powered off at the same time that >> Computer A comes on) Interesting though I'm not sure where I'd use it >> and how it would work if I had a running computer B and it was using >> that device :) > > No, computer B can remain powered on all the time. Imagine computer A being > a Pandaboard with power controlled by computer B, a PC. Now the PC can > power off the Pandaboard, write an image to the card, and power on the Panda > again. This allows fully automatic recovery from a bad boot loader/kernel. Ah thanks - that makes a lot more sense now. Ramana > > -- > Mans Rullgard / mru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Perf record format portability
Em Tue, May 15, 2012 at 07:27:39PM +0400, Dmitry Antipov escreveu: > Hello, > > are there any thoughts on how much of the perf.data is portable and how much > it should be? > I'm interesting in recording scheduler activity on one machine and then > replaying on > another. As I can see, replaying x86 perf.data on ARM doesn't work. At least, > should it > work with a small subset of recorded events (for example, sched:sched_switch, > sched:sched_process_exit, sched:sched_process_fork, sched:sched_wakeup > and sched:sched_migrate_task) on the same architecture? Endianness issues? ARM EB? There are some patches by Jiri Olsa that may help you if that is the case. It should be portable, are you using 'perf archive' too? What exactly is the error experienced? - Arnaldo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Standardized kernel interface for 2D blitters
Hi Christian, Yes dma-buf is part of the picture, but rather if any work has been done to define an interface for the device itself, not the buffers. I do know that these are mostly managed from user-space for performance reasons, however I was curious to see if anything has been in the works for kernel-space (kind of drm but for much more tailored for 2D blitters). -Ilyes On Tue, May 15, 2012 at 3:14 PM, Christian Robottom Reis wrote: > On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: >> I've previously read (probably on Phoronix) that Linaro is working out >> a 'standard' kernel interface for 2D blitters IPs as commonly found on >> SoCs. >> >> Has it ever been the case? If yes, are there any >> documentation/references online? > > I wonder if you are talking about dma-buf and the other collection of > work around Unified Memory Management: > > https://wiki.linaro.org/OfficeofCTO/MemoryManagement > > It's not really specific for 2D blitter IPs, but it does define how > memory can be allocated and shared between different devices, > particularly between the CPU, display controller and GPU IP. > -- > Christian Robottom Reis, Engineering VP > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Standardized kernel interface for 2D blitters
Can you point out the article you're referring to that mentioned the Linaro project? There's nothing I'm aware of that would define what you are asking (apart from the Xserver's EXA framework which certainly isn't new or in the kernel). Even the interfaces exported by DRM require user space code to orchestrate them (i.e., no kernel acceleration in the purest sense). cheers, Jesse On Tue, May 15, 2012 at 5:59 PM, Ilyes Gouta wrote: > Hi Christian, > > Yes dma-buf is part of the picture, but rather if any work has been > done to define an interface for the device itself, not the buffers. > > I do know that these are mostly managed from user-space for > performance reasons, however I was curious to see if anything has been > in the works for kernel-space (kind of drm but for much more tailored > for 2D blitters). > > -Ilyes > > On Tue, May 15, 2012 at 3:14 PM, Christian Robottom Reis > wrote: >> On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: >>> I've previously read (probably on Phoronix) that Linaro is working out >>> a 'standard' kernel interface for 2D blitters IPs as commonly found on >>> SoCs. >>> >>> Has it ever been the case? If yes, are there any >>> documentation/references online? >> >> I wonder if you are talking about dma-buf and the other collection of >> work around Unified Memory Management: >> >> https://wiki.linaro.org/OfficeofCTO/MemoryManagement >> >> It's not really specific for 2D blitter IPs, but it does define how >> memory can be allocated and shared between different devices, >> particularly between the CPU, display controller and GPU IP. >> -- >> Christian Robottom Reis, Engineering VP >> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 >> Linaro.org: Open Source Software for ARM SoCs > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
Tony Lindgren writes:
> * Javier Martinez Canillas [120427 02:33]:
>> On Wed, Apr 25, 2012 at 9:59 AM, Enric Balletbò i Serra
>> wrote:
>> >
>> > Tony, as this is a fix ,may be included ?
>> >
>> > Acked-by: Enric Balletbo i Serra
>> > Tested-by: Enric Balletbo i Serra
>> >
>> > Cheers,
>> > Enric
>>
>> Hi Tony, Russel:
>>
>> This patch is a requirement for patch:
>>
>> [RESEND PATCH 2/2] OMAP3: igep0020: Add support for Micron NAND Flash
>> storage memory
>>
>> which is really important since newer IGEPv2 boards have changed their
>> flash memory from OneNAND to NAND.
>>
>> This patch-set is necessary to make the board work, otherwise it
>> doesn't even boot.
>>
>> Could we please include these patches?
>
> Thanks for the patience, applying now into board branch finally.
This patch breaks the build for platforms that don't use ONENAND.
Using omap2plus_defconfig, set CONFIG_MTD_ONENAND_OMAP2=n and you'll get
the build error below[1]
By removing the static, there is now duplicate definitions in the .c and
.h files.
The solution is to remove the dummy definition from the .c file.
Tony, feel free to fold the diff below[2] into the original patch to fix
this compile problem.
Kevin
[1]
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error:
redefinition of 'board_onenand_init'
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous
definition of 'board_onenand_init' was here
make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [arch/arm/mach-omap2] Error 2
make: *** [sub-make] Error 2
[2]
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 70a81f9..53c39d2 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -97,11 +97,6 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
gpmc_onenand_init(&board_onenand_data);
}
-#else
-void
-__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
-{
-}
#endif /* CONFIG_MTD_ONENAND_OMAP2 || CONFIG_MTD_ONENAND_OMAP2_MODULE */
#if defined(CONFIG_MTD_NAND_OMAP2) || \
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Standardized kernel interface for 2D blitters
Hi Jesse, Here: http://www.phoronix.com/scan.php?page=news_item&px=OTI0MA and http://lists.freedesktop.org/archives/wayland-devel/2011-March/000855.html It doesn't propose a unified interface for 2D accelerators on SoCs, though. > There's nothing I'm aware of that would define what you are asking > (apart from the Xserver's EXA framework which certainly isn't new or Yes, but that's heavily geared towards X11. > in the kernel). Even the interfaces exported by DRM require user > space code to orchestrate them (i.e., no kernel acceleration in the > purest sense). It just that it's kind of common that SoCs have separate IPs for handling 2D and 3D acceleration, not like PC world. And client code could live on both kernel and user lands, hence a need for arbitration and so on. I was just asking, out of curiosity. -Ilyes On Tue, May 15, 2012 at 6:11 PM, Jesse Barker wrote: > Can you point out the article you're referring to that mentioned the > Linaro project? > > There's nothing I'm aware of that would define what you are asking > (apart from the Xserver's EXA framework which certainly isn't new or > in the kernel). Even the interfaces exported by DRM require user > space code to orchestrate them (i.e., no kernel acceleration in the > purest sense). > > cheers, > Jesse > > On Tue, May 15, 2012 at 5:59 PM, Ilyes Gouta wrote: >> Hi Christian, >> >> Yes dma-buf is part of the picture, but rather if any work has been >> done to define an interface for the device itself, not the buffers. >> >> I do know that these are mostly managed from user-space for >> performance reasons, however I was curious to see if anything has been >> in the works for kernel-space (kind of drm but for much more tailored >> for 2D blitters). >> >> -Ilyes >> >> On Tue, May 15, 2012 at 3:14 PM, Christian Robottom Reis >> wrote: >>> On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: I've previously read (probably on Phoronix) that Linaro is working out a 'standard' kernel interface for 2D blitters IPs as commonly found on SoCs. Has it ever been the case? If yes, are there any documentation/references online? >>> >>> I wonder if you are talking about dma-buf and the other collection of >>> work around Unified Memory Management: >>> >>> https://wiki.linaro.org/OfficeofCTO/MemoryManagement >>> >>> It's not really specific for 2D blitter IPs, but it does define how >>> memory can be allocated and shared between different devices, >>> particularly between the CPU, display controller and GPU IP. >>> -- >>> Christian Robottom Reis, Engineering VP >>> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 >>> Linaro.org: Open Source Software for ARM SoCs >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Standardized kernel interface for 2D blitters
OK, so with respect to that article, we've been working with our members to provide KMS drivers for their SoCs. The results are in varying states of completeness and availability, but I would expect that to improve in the coming cycles. You should be able to find DRM drivers for pandaboard (omapdrm: see http://www.phoronix.com/scan.php?page=news_item&px=MTA5MDg) and origen (exynos - this driver is already upstream in drivers/gpu/drm/exynos) with patches out for review on those all the time on the dri-devel list. Snowball support has not quite made it to igloocommunity, but that should be in progress. It's a work in progress, but we are making that progress all the time. I hope this helps. cheers, Jesse On Tue, May 15, 2012 at 7:45 PM, Ilyes Gouta wrote: > Hi Jesse, > > Here: http://www.phoronix.com/scan.php?page=news_item&px=OTI0MA and > http://lists.freedesktop.org/archives/wayland-devel/2011-March/000855.html > > It doesn't propose a unified interface for 2D accelerators on SoCs, though. > >> There's nothing I'm aware of that would define what you are asking >> (apart from the Xserver's EXA framework which certainly isn't new or > > Yes, but that's heavily geared towards X11. > >> in the kernel). Even the interfaces exported by DRM require user >> space code to orchestrate them (i.e., no kernel acceleration in the >> purest sense). > > It just that it's kind of common that SoCs have separate IPs for > handling 2D and 3D acceleration, not like PC world. And client code > could live on both kernel and user lands, hence a need for arbitration > and so on. > > I was just asking, out of curiosity. > > -Ilyes > > On Tue, May 15, 2012 at 6:11 PM, Jesse Barker wrote: >> Can you point out the article you're referring to that mentioned the >> Linaro project? >> >> There's nothing I'm aware of that would define what you are asking >> (apart from the Xserver's EXA framework which certainly isn't new or >> in the kernel). Even the interfaces exported by DRM require user >> space code to orchestrate them (i.e., no kernel acceleration in the >> purest sense). >> >> cheers, >> Jesse >> >> On Tue, May 15, 2012 at 5:59 PM, Ilyes Gouta wrote: >>> Hi Christian, >>> >>> Yes dma-buf is part of the picture, but rather if any work has been >>> done to define an interface for the device itself, not the buffers. >>> >>> I do know that these are mostly managed from user-space for >>> performance reasons, however I was curious to see if anything has been >>> in the works for kernel-space (kind of drm but for much more tailored >>> for 2D blitters). >>> >>> -Ilyes >>> >>> On Tue, May 15, 2012 at 3:14 PM, Christian Robottom Reis >>> wrote: On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: > I've previously read (probably on Phoronix) that Linaro is working out > a 'standard' kernel interface for 2D blitters IPs as commonly found on > SoCs. > > Has it ever been the case? If yes, are there any > documentation/references online? I wonder if you are talking about dma-buf and the other collection of work around Unified Memory Management: https://wiki.linaro.org/OfficeofCTO/MemoryManagement It's not really specific for 2D blitter IPs, but it does define how memory can be allocated and shared between different devices, particularly between the CPU, display controller and GPU IP. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs >>> >>> ___ >>> linaro-dev mailing list >>> linaro-dev@lists.linaro.org >>> http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Standardized kernel interface for 2D blitters
Thanks for the references! -Ilyes On Tue, May 15, 2012 at 8:03 PM, Jesse Barker wrote: > OK, so with respect to that article, we've been working with our > members to provide KMS drivers for their SoCs. The results are in > varying states of completeness and availability, but I would expect > that to improve in the coming cycles. You should be able to find DRM > drivers for pandaboard (omapdrm: see > http://www.phoronix.com/scan.php?page=news_item&px=MTA5MDg) and origen > (exynos - this driver is already upstream in drivers/gpu/drm/exynos) > with patches out for review on those all the time on the dri-devel > list. Snowball support has not quite made it to igloocommunity, but > that should be in progress. > > It's a work in progress, but we are making that progress all the time. > > I hope this helps. > > cheers, > Jesse > > On Tue, May 15, 2012 at 7:45 PM, Ilyes Gouta wrote: >> Hi Jesse, >> >> Here: http://www.phoronix.com/scan.php?page=news_item&px=OTI0MA and >> http://lists.freedesktop.org/archives/wayland-devel/2011-March/000855.html >> >> It doesn't propose a unified interface for 2D accelerators on SoCs, though. >> >>> There's nothing I'm aware of that would define what you are asking >>> (apart from the Xserver's EXA framework which certainly isn't new or >> >> Yes, but that's heavily geared towards X11. >> >>> in the kernel). Even the interfaces exported by DRM require user >>> space code to orchestrate them (i.e., no kernel acceleration in the >>> purest sense). >> >> It just that it's kind of common that SoCs have separate IPs for >> handling 2D and 3D acceleration, not like PC world. And client code >> could live on both kernel and user lands, hence a need for arbitration >> and so on. >> >> I was just asking, out of curiosity. >> >> -Ilyes >> >> On Tue, May 15, 2012 at 6:11 PM, Jesse Barker >> wrote: >>> Can you point out the article you're referring to that mentioned the >>> Linaro project? >>> >>> There's nothing I'm aware of that would define what you are asking >>> (apart from the Xserver's EXA framework which certainly isn't new or >>> in the kernel). Even the interfaces exported by DRM require user >>> space code to orchestrate them (i.e., no kernel acceleration in the >>> purest sense). >>> >>> cheers, >>> Jesse >>> >>> On Tue, May 15, 2012 at 5:59 PM, Ilyes Gouta wrote: Hi Christian, Yes dma-buf is part of the picture, but rather if any work has been done to define an interface for the device itself, not the buffers. I do know that these are mostly managed from user-space for performance reasons, however I was curious to see if anything has been in the works for kernel-space (kind of drm but for much more tailored for 2D blitters). -Ilyes On Tue, May 15, 2012 at 3:14 PM, Christian Robottom Reis wrote: > On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: >> I've previously read (probably on Phoronix) that Linaro is working out >> a 'standard' kernel interface for 2D blitters IPs as commonly found on >> SoCs. >> >> Has it ever been the case? If yes, are there any >> documentation/references online? > > I wonder if you are talking about dma-buf and the other collection of > work around Unified Memory Management: > > https://wiki.linaro.org/OfficeofCTO/MemoryManagement > > It's not really specific for 2D blitter IPs, but it does define how > memory can be allocated and shared between different devices, > particularly between the CPU, display controller and GPU IP. > -- > Christian Robottom Reis, Engineering VP > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Standardized kernel interface for 2D blitters
Thanks for the references! -Ilyes On Tue, May 15, 2012 at 8:03 PM, Jesse Barker wrote: > OK, so with respect to that article, we've been working with our > members to provide KMS drivers for their SoCs. The results are in > varying states of completeness and availability, but I would expect > that to improve in the coming cycles. You should be able to find DRM > drivers for pandaboard (omapdrm: see > http://www.phoronix.com/scan.php?page=news_item&px=MTA5MDg) and origen > (exynos - this driver is already upstream in drivers/gpu/drm/exynos) > with patches out for review on those all the time on the dri-devel > list. Snowball support has not quite made it to igloocommunity, but > that should be in progress. > > It's a work in progress, but we are making that progress all the time. > > I hope this helps. > > cheers, > Jesse > > On Tue, May 15, 2012 at 7:45 PM, Ilyes Gouta wrote: >> Hi Jesse, >> >> Here: http://www.phoronix.com/scan.php?page=news_item&px=OTI0MA and >> http://lists.freedesktop.org/archives/wayland-devel/2011-March/000855.html >> >> It doesn't propose a unified interface for 2D accelerators on SoCs, though. >> >>> There's nothing I'm aware of that would define what you are asking >>> (apart from the Xserver's EXA framework which certainly isn't new or >> >> Yes, but that's heavily geared towards X11. >> >>> in the kernel). Even the interfaces exported by DRM require user >>> space code to orchestrate them (i.e., no kernel acceleration in the >>> purest sense). >> >> It just that it's kind of common that SoCs have separate IPs for >> handling 2D and 3D acceleration, not like PC world. And client code >> could live on both kernel and user lands, hence a need for arbitration >> and so on. >> >> I was just asking, out of curiosity. >> >> -Ilyes >> >> On Tue, May 15, 2012 at 6:11 PM, Jesse Barker >> wrote: >>> Can you point out the article you're referring to that mentioned the >>> Linaro project? >>> >>> There's nothing I'm aware of that would define what you are asking >>> (apart from the Xserver's EXA framework which certainly isn't new or >>> in the kernel). Even the interfaces exported by DRM require user >>> space code to orchestrate them (i.e., no kernel acceleration in the >>> purest sense). >>> >>> cheers, >>> Jesse >>> >>> On Tue, May 15, 2012 at 5:59 PM, Ilyes Gouta wrote: Hi Christian, Yes dma-buf is part of the picture, but rather if any work has been done to define an interface for the device itself, not the buffers. I do know that these are mostly managed from user-space for performance reasons, however I was curious to see if anything has been in the works for kernel-space (kind of drm but for much more tailored for 2D blitters). -Ilyes On Tue, May 15, 2012 at 3:14 PM, Christian Robottom Reis wrote: > On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: >> I've previously read (probably on Phoronix) that Linaro is working out >> a 'standard' kernel interface for 2D blitters IPs as commonly found on >> SoCs. >> >> Has it ever been the case? If yes, are there any >> documentation/references online? > > I wonder if you are talking about dma-buf and the other collection of > work around Unified Memory Management: > > https://wiki.linaro.org/OfficeofCTO/MemoryManagement > > It's not really specific for 2D blitter IPs, but it does define how > memory can be allocated and shared between different devices, > particularly between the CPU, display controller and GPU IP. > -- > Christian Robottom Reis, Engineering VP > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
* Kevin Hilman [120515 11:17]:
> Tony Lindgren writes:
>
> > * Javier Martinez Canillas [120427 02:33]:
> >> On Wed, Apr 25, 2012 at 9:59 AM, Enric Balletbò i Serra
> >> wrote:
> >> >
> >> > Tony, as this is a fix ,may be included ?
> >> >
> >> > Acked-by: Enric Balletbo i Serra
> >> > Tested-by: Enric Balletbo i Serra
> >> >
> >> > Cheers,
> >> > Enric
> >>
> >> Hi Tony, Russel:
> >>
> >> This patch is a requirement for patch:
> >>
> >> [RESEND PATCH 2/2] OMAP3: igep0020: Add support for Micron NAND Flash
> >> storage memory
> >>
> >> which is really important since newer IGEPv2 boards have changed their
> >> flash memory from OneNAND to NAND.
> >>
> >> This patch-set is necessary to make the board work, otherwise it
> >> doesn't even boot.
> >>
> >> Could we please include these patches?
> >
> > Thanks for the patience, applying now into board branch finally.
>
> This patch breaks the build for platforms that don't use ONENAND.
> Using omap2plus_defconfig, set CONFIG_MTD_ONENAND_OMAP2=n and you'll get
> the build error below[1]
Thanks for catching that.
> By removing the static, there is now duplicate definitions in the .c and
> .h files.
>
> The solution is to remove the dummy definition from the .c file.
>
> Tony, feel free to fold the diff below[2] into the original patch to fix
> this compile problem.
That's already merged as 8259573b (ARM: OMAP2+: nand: Make board_onenand_init()
visible to board code) so we need to apply it as a fix.
Can you do a fix with your Signed-off-by or at least reply with that
so I can apply it?
Thanks,
Tony
> [1]
> /work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error:
> redefinition of 'board_onenand_init'
> /work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous
> definition of 'board_onenand_init' was here
> make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[1]: *** [arch/arm/mach-omap2] Error 2
> make: *** [sub-make] Error 2
>
> [2]
> diff --git a/arch/arm/mach-omap2/board-flash.c
> b/arch/arm/mach-omap2/board-flash.c
> index 70a81f9..53c39d2 100644
> --- a/arch/arm/mach-omap2/board-flash.c
> +++ b/arch/arm/mach-omap2/board-flash.c
> @@ -97,11 +97,6 @@ __init board_onenand_init(struct mtd_partition
> *onenand_parts,
>
> gpmc_onenand_init(&board_onenand_data);
> }
> -#else
> -void
> -__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8
> cs)
> -{
> -}
> #endif /* CONFIG_MTD_ONENAND_OMAP2 || CONFIG_MTD_ONENAND_OMAP2_MODULE */
>
> #if defined(CONFIG_MTD_NAND_OMAP2) || \
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
Tony Lindgren writes:
[...]
> That's already merged as 8259573b (ARM: OMAP2+: nand: Make
> board_onenand_init()
> visible to board code) so we need to apply it as a fix.
>
> Can you do a fix with your Signed-off-by or at least reply with that
> so I can apply it?
Here you go. Applies to your 'board' branch.
Kevin
From f4f2c35de0e67e3b8185059ffd78be67f7096d8a Mon Sep 17 00:00:00 2001
From: Kevin Hilman
Date: Tue, 15 May 2012 13:07:20 -0700
Subject: [PATCH] ARM: OMAP2+: nand: fix build error when
CONFIG_MTD_ONENAND_OMAP2=n
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
commit 8259573b (ARM: OMAP2+: nand: Make board_onenand_init() visible
to board code) broke the build for configs with OneNAND disabled. By
removing the static in the header file, it created a duplicate definition
in the .c and the .h files, resuling in a build error:
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error:
redefinition of 'board_onenand_init'
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous
definition of 'board_onenand_init' was here
make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [arch/arm/mach-omap2] Error 2
make: *** [sub-make] Error 2
Fix this by removing the duplicate dummy entry from the C file.
Cc: Enric Balletbò i Serra
Cc: Javier Martinez Canillas
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/board-flash.c |5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 70a81f9..53c39d2 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -97,11 +97,6 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
gpmc_onenand_init(&board_onenand_data);
}
-#else
-void
-__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
-{
-}
#endif /* CONFIG_MTD_ONENAND_OMAP2 || CONFIG_MTD_ONENAND_OMAP2_MODULE */
#if defined(CONFIG_MTD_NAND_OMAP2) || \
--
1.7.9.2
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
* Kevin Hilman [120515 13:17]: > Tony Lindgren writes: > > [...] > > > That's already merged as 8259573b (ARM: OMAP2+: nand: Make > > board_onenand_init() > > visible to board code) so we need to apply it as a fix. > > > > Can you do a fix with your Signed-off-by or at least reply with that > > so I can apply it? > > Here you go. Applies to your 'board' branch. Thanks applying into fixes-board branch. Tony ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Agenda for Linaro Android Team Meeting Posted
The agenda's at: https://wiki.linaro.org/Platform/Android/Meetings/2012-05-16 Feel free to add to it, etc... For Android team members, please post your status. See you tomorrow! -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v1] AudiVal (Audio Validation Suite for Linux)
Cool, does this replace the existing e2daudiotest I guess? Also, has it
already been shown to work on all of the listed board?
On Tue, May 15, 2012 at 9:00 AM, Harsh Prateek Bora
wrote:
>AudiVal (Audio Validation Suite for Linux)
>
> This is an attempt to automate and integrate various audio related tests
> which
> can help validate audio on various boards supported by Linaro. Motivation
> for
> this project comes from various audio tests listed at:
> https://wiki.linaro.org/TomGall/LinaroAudioFeatureIndex
>
> The git repo for this project can be cloned from:
> git://git.linaro.org/people/harshbora/audival.git
>
> Various files required by this script are available in the git repo.
>
> Requesting all to test this script on various boards that you may have
> access
> to and share feedback to make it better.
>
> TODO: Add tests for Audio over USB, Bluetooth.
>
> Signed-off-by: Harsh Prateek Bora
>
> diff --git a/AudiVal.py b/AudiVal.py
> new file mode 100755
> index 000..7d56c4e
> --- /dev/null
> +++ b/AudiVal.py
> @@ -0,0 +1,247 @@
> +#!/usr/bin/env python
> +#
> +# Audival : Audio Validation Suite for Linux.
> +#
> +# Author: Harsh Prateek Bora
> +#
> +#
> +
> +import os
> +import sys
> +import getopt
> +from subprocess import * # for calling external programs
> +import commands # deprecated since python 2.6, Python 3.0 uses subprocess
> +
> +def usage():
> +print "="
> +print "AudiVal: Audio Validation Suite for Linux"
> +print "="
> +print "Usage:"
> +print sys.argv[0], "[--check-info]"
> +print
> +print "Supported HW: PandaBoard (ES), BeagleBoard (XM), i.MX53,
> i.MX6, Origen, Snowball"
> +sys.exit(1)
> +
> +SpeakerJack = {
> +'GenuineIntel': 'Analog',
> +'Panda':'Headset',
> +'Beagle': 'TWL4030',
> +'i.MX53': 'HiFi',
> +'i.MX6':'HiFi',
> +'ORIGEN': 'Pri_Dai',
> +'Snowball': 'Headset'
> +}
> +
> +MicJack = {
> +'GenuineIntel': 'Analog',
> +'Panda':'Headset', # not sure though, arecord doesnt work
> for me!
> +'Beagle': 'TWL4030',
> +'i.MX53': 'HiFi',
> +'i.MX6':'HiFi',
> +'ORIGEN': 'Pri_Dai',
> +'Snowball': 'Headset'
> +}
> +
> +# As and when HDMI out/in device string differs, we'll need 2
> dictionaries.
> +HDMI_Audio = {
> +'GenuineIntel': 'HDMI',
> +'Panda':'HDMI',
> +'Beagle': 'HDMI',
> +'i.MX53': 'HDMI',
> +'i.MX6':'HDMI', # audio out only supported, audio in not
> supported.
> +'ORIGEN': 'HDMI',
> +'Snowball': 'hdmi' # odd one, lowercase
> +}
> +
> +Audio_Devices = {
> +'playback':'aplay-l.log',
> +'capture': 'arecord-l.log'
> +}
> +
> +def get_device_list(logfile):
> +fobj = open(logfile)
> +return fobj
> +
> +def get_card_device_info_by_name(devicestr, fobj):
> +"""Helper routine to get card, device number by interface name"""
> +optxt = fobj.readlines()
> +card = ""
> +device = ""
> +for line in optxt:
> +if devicestr in line:
> +cardtext, colon, text = line.partition(':')
> +pre, sep, card = cardtext.partition(' ')
> +devtext, colon, text = text.partition(':')
> +pre, sep, device = devtext.partition('device ')
> +break
> +hwstr = 'plughw:' + card + ',' + device
> +if card is "" and device is "":
> +return None
> +return hwstr
> +
> +def speaker_test_audio_jack(board):
> +fobj = get_device_list(Audio_Devices['playback'])
> +print "speaker-test over audio jack .."
> +headset_jack_id = get_card_device_info_by_name(SpeakerJack[board],
> fobj)
> +fobj.close()
> +if headset_jack_id is None:
> +print "No Audio Jack found !"
> +return
> +call("date > speaker-test-jack.log", shell=True)
> +cmdstr = "speaker-test -D " + headset_jack_id + " -t s -c 2 -l 1 >
> speaker-test-jack.log 2>&1"
> +call(cmdstr, shell=True)
> +print "If you heard beeps from left and right speaker, test passed."
> +
> +def aplay_over_jack(board):
> +fobj = get_device_list(Audio_Devices['playback'])
> +headset_jack_id = get_card_device_info_by_name(SpeakerJack[board],
> fobj)
> +print "Testing aplay over audio jack .."
> +fobj.close()
> +if headset_jack_id is None:
> +print "No Audio Jack found !"
> +return
> +cmdstr = "aplay login.wav -D " + headset_jack_id
> +call(cmdstr, shell=True)
> +print "If you heard a stereo sound, test passed."
> +# Check dmesg to see if there is an error or I2C error
> +call("dmesg | tail | grep error", shell=True)
> +print "Note: Error, if any, shall be displayed above."
> +
> +def arecord_and_aplay_over_audio_jack(board):
> +# Record the WAV st
Re: [RFC PATCH v1] AudiVal (Audio Validation Suite for Linux)
HI Paul,
On Tue, May 15, 2012 at 4:14 PM, Paul Larson wrote:
> Cool, does this replace the existing e2daudiotest I guess?
Please consider it as complementary.
> Also, has it
> already been shown to work on all of the listed board?
Yes but that's not to say there aren't issues here and there for a
variety of reasons!
Regards,
Tom
> On Tue, May 15, 2012 at 9:00 AM, Harsh Prateek Bora
> wrote:
>>
>> AudiVal (Audio Validation Suite for Linux)
>>
>> This is an attempt to automate and integrate various audio related tests
>> which
>> can help validate audio on various boards supported by Linaro. Motivation
>> for
>> this project comes from various audio tests listed at:
>> https://wiki.linaro.org/TomGall/LinaroAudioFeatureIndex
>>
>> The git repo for this project can be cloned from:
>> git://git.linaro.org/people/harshbora/audival.git
>>
>> Various files required by this script are available in the git repo.
>>
>> Requesting all to test this script on various boards that you may have
>> access
>> to and share feedback to make it better.
>>
>> TODO: Add tests for Audio over USB, Bluetooth.
>>
>> Signed-off-by: Harsh Prateek Bora
>>
>> diff --git a/AudiVal.py b/AudiVal.py
>> new file mode 100755
>> index 000..7d56c4e
>> --- /dev/null
>> +++ b/AudiVal.py
>> @@ -0,0 +1,247 @@
>> +#!/usr/bin/env python
>> +#
>> +# Audival : Audio Validation Suite for Linux.
>> +#
>> +# Author: Harsh Prateek Bora
>> +#
>> +#
>> +
>> +import os
>> +import sys
>> +import getopt
>> +from subprocess import * # for calling external programs
>> +import commands # deprecated since python 2.6, Python 3.0 uses subprocess
>> +
>> +def usage():
>> + print "="
>> + print "AudiVal: Audio Validation Suite for Linux"
>> + print "="
>> + print "Usage:"
>> + print sys.argv[0], "[--check-info]"
>> + print
>> + print "Supported HW: PandaBoard (ES), BeagleBoard (XM), i.MX53,
>> i.MX6, Origen, Snowball"
>> + sys.exit(1)
>> +
>> +SpeakerJack = {
>> + 'GenuineIntel': 'Analog',
>> + 'Panda': 'Headset',
>> + 'Beagle': 'TWL4030',
>> + 'i.MX53': 'HiFi',
>> + 'i.MX6': 'HiFi',
>> + 'ORIGEN': 'Pri_Dai',
>> + 'Snowball': 'Headset'
>> +}
>> +
>> +MicJack = {
>> + 'GenuineIntel': 'Analog',
>> + 'Panda': 'Headset', # not sure though, arecord doesnt work
>> for me!
>> + 'Beagle': 'TWL4030',
>> + 'i.MX53': 'HiFi',
>> + 'i.MX6': 'HiFi',
>> + 'ORIGEN': 'Pri_Dai',
>> + 'Snowball': 'Headset'
>> +}
>> +
>> +# As and when HDMI out/in device string differs, we'll need 2
>> dictionaries.
>> +HDMI_Audio = {
>> + 'GenuineIntel': 'HDMI',
>> + 'Panda': 'HDMI',
>> + 'Beagle': 'HDMI',
>> + 'i.MX53': 'HDMI',
>> + 'i.MX6': 'HDMI', # audio out only supported, audio in not
>> supported.
>> + 'ORIGEN': 'HDMI',
>> + 'Snowball': 'hdmi' # odd one, lowercase
>> +}
>> +
>> +Audio_Devices = {
>> + 'playback': 'aplay-l.log',
>> + 'capture': 'arecord-l.log'
>> +}
>> +
>> +def get_device_list(logfile):
>> + fobj = open(logfile)
>> + return fobj
>> +
>> +def get_card_device_info_by_name(devicestr, fobj):
>> + """Helper routine to get card, device number by interface name"""
>> + optxt = fobj.readlines()
>> + card = ""
>> + device = ""
>> + for line in optxt:
>> + if devicestr in line:
>> + cardtext, colon, text = line.partition(':')
>> + pre, sep, card = cardtext.partition(' ')
>> + devtext, colon, text = text.partition(':')
>> + pre, sep, device = devtext.partition('device ')
>> + break
>> + hwstr = 'plughw:' + card + ',' + device
>> + if card is "" and device is "":
>> + return None
>> + return hwstr
>> +
>> +def speaker_test_audio_jack(board):
>> + fobj = get_device_list(Audio_Devices['playback'])
>> + print "speaker-test over audio jack .."
>> + headset_jack_id = get_card_device_info_by_name(SpeakerJack[board],
>> fobj)
>> + fobj.close()
>> + if headset_jack_id is None:
>> + print "No Audio Jack found !"
>> + return
>> + call("date > speaker-test-jack.log", shell=True)
>> + cmdstr = "speaker-test -D " + headset_jack_id + " -t s -c 2 -l 1 >
>> speaker-test-jack.log 2>&1"
>> + call(cmdstr, shell=True)
>> + print "If you heard beeps from left and right speaker, test passed."
>> +
>> +def aplay_over_jack(board):
>> + fobj = get_device_list(Audio_Devices['playback'])
>> + headset_jack_id = get_card_device_info_by_name(SpeakerJack[board],
>> fobj)
>> + print "Testing aplay over audio jack .."
>> + fobj.close()
>> + if headset_jack_id is None:
>> + print "No Audio Jack found !"
>> + return
>> + cmdstr = "aplay login.wav -D " + headse
Re: [PATCH 0/3] OMAP: control: bootaddr and bootmod APIs
On 2 May 2012 21:11, Omar Ramirez Luna wrote: > Recently a patch went in for tidspbridge code, to ioremap > SCM registers and solve a build break[1]. However it has > been pointed out before that this is a layer violation > given that control module should handle its own registers, this > series is an attempt to create APIs for the users of these > registers. > > With some adaptations this patch might also make use of it: > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66491.html > > Patch: staging: tidspbridge: use scm functions to set boot address and mode, > will be sent separately to staging tree. > > Tested on OMAP3 Beagleboard. > > [1] http://www.mail-archive.com/devel@linuxdriverproject.org/msg18762.html > > Omar Ramirez Luna (3): > OMAP2+: control: new APIs to configure boot address and mode > OMAP: dsp: interface to control module functions > staging: tidspbridge: use scm functions to set boot address and mode Ping. It seems that I unconsciously copied the previous concept, recently I dug this thread to explain the reasoning of these patches: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38015.html These were provided by Paul, one of them acked by Kevin, somehow they were not included and I forgot about them. My set also includes OMAP4 check, which I heard recently was tested with the dsp on pandaboard. If needed I can go back to Paul's version and re-spin them, with minor changes. Please let me know. Regards, Omar ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v4 7/7] ARM: imx: Add imx6q cpuidle driver
Add basic imx6q cpuidle driver. For now, only basic WFI state is
supported. Deeper idle states will be added in the future.
Signed-off-by: Robert Lee
---
arch/arm/mach-imx/mach-imx6q.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index da6c1d9..4fc1fe7 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -10,7 +10,9 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#include
#include
+#include
#include
#include
#include
@@ -21,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -28,8 +31,10 @@
#include
#include
#include
+#include
#include
+
void imx6q_restart(char mode, const char *cmd)
{
struct device_node *np;
@@ -86,6 +91,19 @@ static void __init imx6q_init_machine(void)
imx6q_pm_init();
}
+static struct cpuidle_driver imx6q_cpuidle_driver = {
+ .name = "imx6q_cpuidle",
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
+ .states[0] = ARM_CPUIDLE_WFI_STATE,
+ .state_count= 1,
+};
+
+static void __init imx6q_init_late(void)
+{
+ imx_cpuidle_init(&imx6q_cpuidle_driver);
+}
+
static void __init imx6q_map_io(void)
{
imx_lluart_map_io();
@@ -142,6 +160,7 @@ DT_MACHINE_START(IMX6Q, "Freescale i.MX6 Quad (Device
Tree)")
.handle_irq = imx6q_handle_irq,
.timer = &imx6q_timer,
.init_machine = imx6q_init_machine,
+ .init_late = imx6q_init_late,
.dt_compat = imx6q_dt_compat,
.restart= imx6q_restart,
MACHINE_END
--
1.7.10
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v4 2/7] ARM: imx: Add comments to tzic_enable_waker()
Add additional comments to the tzic_enable_wake() funciton to
clarify its intended usage.
Signed-off-by: Robert Lee
---
arch/arm/plat-mxc/tzic.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/plat-mxc/tzic.c b/arch/arm/plat-mxc/tzic.c
index 98308ec..a45dbea 100644
--- a/arch/arm/plat-mxc/tzic.c
+++ b/arch/arm/plat-mxc/tzic.c
@@ -190,6 +190,10 @@ void __init tzic_init_irq(void __iomem *irqbase)
* tzic_enable_wake() - enable wakeup interrupt
*
* @return 0 if successful; non-zero otherwise
+ *
+ * This function provides an interrupt synchronization point that is required
+ * by tzic enabled platforms before entering imx specific low power modes (ie,
+ * those low power modes beyond the WAIT_CLOCKED basic ARM WFI only mode).
*/
int tzic_enable_wake(void)
{
--
1.7.10
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v4 3/7] ARM: imx: clean and consolidate imx5 suspend and idle code
The imx5 idle code that existed in mm-imx5.c is moved to pm-imx5.c.
The imx5_pm_init call is now exported and called during the
MACHINE_START late_init in supported imx5 platforms.
Remove various enabling/disabling of the gpc_dvfs clock and
enable it once during initialization. This is a very low
power clock that must be enabled during low power operations.
There are only two "suspend_state_t" imx5 low power modes ever
used. STOP_POWER_OFF for suspend to mem and
WAIT_UNCLOCKED_POWER_OFF for idle and suspend to standby. The
latter mode only requires 500 nanoseconds of extra hardware
exit time beyond a basic WFI operation (WAIT_CLOCKED mode) so
no other idle mode is necessary. Given this information, it
is more efficient to keep the registers in the often used
WAIT_UNCLOCKED_POWER_OFF state and only to and from the
STOP_POWER_OFF register state as needed when suspend to
mem is required.
Signed-off-by: Robert Lee
---
arch/arm/mach-imx/mm-imx5.c | 20 +-
arch/arm/mach-imx/pm-imx5.c | 63 ++-
arch/arm/plat-mxc/include/mach/common.h |3 +-
3 files changed, 40 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c
index d6b7e9f..bb38747 100644
--- a/arch/arm/mach-imx/mm-imx5.c
+++ b/arch/arm/mach-imx/mm-imx5.c
@@ -15,7 +15,6 @@
#include
#include
-#include
#include
#include
@@ -23,23 +22,6 @@
#include
#include
-static struct clk *gpc_dvfs_clk;
-
-static void imx5_idle(void)
-{
- /* gpc clock is needed for SRPG */
- if (gpc_dvfs_clk == NULL) {
- gpc_dvfs_clk = clk_get(NULL, "gpc_dvfs");
- if (IS_ERR(gpc_dvfs_clk))
- return;
- }
- clk_enable(gpc_dvfs_clk);
- mx5_cpu_lp_set(WAIT_UNCLOCKED_POWER_OFF);
- if (!tzic_enable_wake())
- cpu_do_idle();
- clk_disable(gpc_dvfs_clk);
-}
-
/*
* Define the MX50 memory map.
*/
@@ -103,7 +85,6 @@ void __init imx51_init_early(void)
mxc_set_cpu_type(MXC_CPU_MX51);
mxc_iomux_v3_init(MX51_IO_ADDRESS(MX51_IOMUXC_BASE_ADDR));
mxc_arch_reset_init(MX51_IO_ADDRESS(MX51_WDOG1_BASE_ADDR));
- arm_pm_idle = imx5_idle;
}
void __init imx53_init_early(void)
@@ -238,4 +219,5 @@ void __init imx53_soc_init(void)
void __init imx51_init_late(void)
{
mx51_neon_fixup();
+ imx5_pm_init();
}
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index e26a9cb..6e62d79 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -13,18 +13,27 @@
#include
#include
#include
+#include
#include
#include
#include
#include "crm-regs-imx5.h"
-static struct clk *gpc_dvfs_clk;
+/*
+ * The WAIT_UNCLOCKED_POWER_OFF state only requires <= 500ns to exit.
+ * This is also the lowest power state possible without affecting
+ * non-cpu parts of the system. For these reasons, imx5 should default
+ * to always using this state for cpu idling. The PM_SUSPEND_STANDBY also
+ * uses this state and needs to take no action when registers remain confgiured
+ * for this state.
+ */
+#define IMX5_DEFAULT_CPU_IDLE_STATE WAIT_UNCLOCKED_POWER_OFF
/*
* set cpu low power mode before WFI instruction. This function is called
* mx5 because it can be used for mx50, mx51, and mx53.
*/
-void mx5_cpu_lp_set(enum mxc_cpu_pwr_mode mode)
+static void mx5_cpu_lp_set(enum mxc_cpu_pwr_mode mode)
{
u32 plat_lpc, arm_srpgcr, ccm_clpcr;
u32 empgc0, empgc1;
@@ -87,11 +96,6 @@ void mx5_cpu_lp_set(enum mxc_cpu_pwr_mode mode)
}
}
-static int mx5_suspend_prepare(void)
-{
- return clk_prepare_enable(gpc_dvfs_clk);
-}
-
static int mx5_suspend_enter(suspend_state_t state)
{
switch (state) {
@@ -99,7 +103,7 @@ static int mx5_suspend_enter(suspend_state_t state)
mx5_cpu_lp_set(STOP_POWER_OFF);
break;
case PM_SUSPEND_STANDBY:
- mx5_cpu_lp_set(WAIT_UNCLOCKED_POWER_OFF);
+ /* DEFAULT_IDLE_STATE already configured */
break;
default:
return -EINVAL;
@@ -114,12 +118,10 @@ static int mx5_suspend_enter(suspend_state_t state)
__raw_writel(0, MXC_SRPG_EMPGC1_SRPGCR);
}
cpu_do_idle();
- return 0;
-}
-static void mx5_suspend_finish(void)
-{
- clk_disable_unprepare(gpc_dvfs_clk);
+ /* return registers to default idle state */
+ mx5_cpu_lp_set(IMX5_DEFAULT_CPU_IDLE_STATE);
+ return 0;
}
static int mx5_pm_valid(suspend_state_t state)
@@ -129,25 +131,34 @@ static int mx5_pm_valid(suspend_state_t state)
static const struct platform_suspend_ops mx5_suspend_ops = {
.valid = mx5_pm_valid,
- .prepare = mx5_suspend_prepare,
.enter = mx5_suspend_enter,
- .finish = mx5_suspend_finish,
};
-static int __init mx5_pm_init(void)
+static void imx5_pm_idle(void)
+{
+ if (likely(!tzi
[PATCH v4 5/7] ARM: imx: Add common imx cpuidle init functionality.
Add common cpuidle init functionality that can be used by various
imx platforms.
Signed-off-by: Robert Lee
---
arch/arm/plat-mxc/Makefile |1 +
arch/arm/plat-mxc/cpuidle.c | 80 ++
arch/arm/plat-mxc/include/mach/cpuidle.h | 22
3 files changed, 103 insertions(+)
create mode 100644 arch/arm/plat-mxc/cpuidle.c
create mode 100644 arch/arm/plat-mxc/include/mach/cpuidle.h
diff --git a/arch/arm/plat-mxc/Makefile b/arch/arm/plat-mxc/Makefile
index e81290c..63b064b 100644
--- a/arch/arm/plat-mxc/Makefile
+++ b/arch/arm/plat-mxc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_MXC_ULPI) += ulpi.o
obj-$(CONFIG_MXC_USE_EPIT) += epit.o
obj-$(CONFIG_MXC_DEBUG_BOARD) += 3ds_debugboard.o
obj-$(CONFIG_CPU_FREQ_IMX)+= cpufreq.o
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o
ifdef CONFIG_SND_IMX_SOC
obj-y += ssi-fiq.o
obj-y += ssi-fiq-ksym.o
diff --git a/arch/arm/plat-mxc/cpuidle.c b/arch/arm/plat-mxc/cpuidle.c
new file mode 100644
index 000..d4cb511
--- /dev/null
+++ b/arch/arm/plat-mxc/cpuidle.c
@@ -0,0 +1,80 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2012 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct cpuidle_device __percpu * imx_cpuidle_devices;
+
+static void __init imx_cpuidle_devices_uninit(void)
+{
+ int cpu_id;
+ struct cpuidle_device *dev;
+
+ for_each_possible_cpu(cpu_id) {
+ dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
+ cpuidle_unregister_device(dev);
+ }
+
+ free_percpu(imx_cpuidle_devices);
+}
+
+int __init imx_cpuidle_init(struct cpuidle_driver *drv)
+{
+ struct cpuidle_device *dev;
+ int cpu_id, ret;
+
+ if (drv->state_count > CPUIDLE_STATE_MAX) {
+ pr_err("%s: state_count exceeds maximum\n", __func__);
+ return -EINVAL;
+ }
+
+ ret = cpuidle_register_driver(drv);
+ if (ret) {
+ pr_err("%s: Failed to register cpuidle driver with error: %d\n",
+__func__, ret);
+ return ret;
+ }
+
+ imx_cpuidle_devices = alloc_percpu(struct cpuidle_device);
+ if (imx_cpuidle_devices == NULL) {
+ ret = -ENOMEM;
+ goto unregister_drv;
+ }
+
+ /* initialize state data for each cpuidle_device */
+ for_each_possible_cpu(cpu_id) {
+ dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
+ dev->cpu = cpu_id;
+ dev->state_count = drv->state_count;
+
+ ret = cpuidle_register_device(dev);
+ if (ret) {
+ pr_err("%s: Failed to register cpu %u, error: %d\n",
+ __func__, cpu_id, ret);
+ goto uninit;
+ }
+ }
+
+ return 0;
+
+uninit:
+ imx_cpuidle_devices_uninit();
+
+unregister_drv:
+ cpuidle_unregister_driver(drv);
+ return ret;
+}
diff --git a/arch/arm/plat-mxc/include/mach/cpuidle.h
b/arch/arm/plat-mxc/include/mach/cpuidle.h
new file mode 100644
index 000..bc932d1
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/cpuidle.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2012 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+
+#ifdef CONFIG_CPU_IDLE
+extern int imx_cpuidle_init(struct cpuidle_driver *drv);
+#else
+static inline int imx_cpuidle_init(struct cpuidle_driver *drv)
+{
+ return -ENODEV;
+}
+#endif
--
1.7.10
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v4 0/7] cleanup imx5 idle, add imx5/6 cpuidle
Cleanup up imx5 idle code and enable imx5 low powe idle for imx53.
Add common imx cpuidle initialization functionality and add a i.MX5 and i.MX6Q
platform cpuidle implementation.
Based on v3.4-rc7 plus recently submitted/accepted MACHINE_INIT late_initcall
patch: http://www.spinics.net/lists/arm-kernel/msg171620.html
v4 changes:
* Added several imx5 idle cleanups to series.
* Modified imx_io_p2v function to allow common imx5 AIPS2 bus virutal address
* Added comment to tzic_wakeup_enable().
* Movied imx5 idle code from mm-imx5.c to pm-imx5.c.
* Removed unnecessary time consuming code execution that ran on each idle
instance.
* modified imx5_pm_init to be a late_initcall
* added late_initcall to all imx53 MACHINE_START entries.
* enabled imx5 low power idle for imx53
* rebased cpuidle driver on top of imx5 cleanup changes.
* modified cpuidle driver exit time to reflect removal of unnecessary code
v3 changes:
* removed file introduced in v1 no longer needed after v2 [per Shawn Guo]
* re-ordered added #includes in alphabetical order [per Shawn Guo]
* Remove if(!drv) check to allow handling by stack trace [per Sascha Hauer]
* Added missing return value in error meesage [per Shawn Guo]
* fixed (void *) casting problem pointed out Sasha Hauer. Used a different
type of casting to properly give warning on improper casting:
arm_pm_idle = (void (*)(void))imx5_idle;
Used this casting instead of adding a dummy caller function because
adding the dummy function appears to unnecessarily introduce the following
additional operations:
static void imx5_pm_idle(void)
{
a0: e1a0c00dmov ip, sp
a4: e92dd800push{fp, ip, lr, pc}
a8: e24cb004sub fp, ip, #4
imx5_idle();
ac: ebd3bl 0
}
b0: e89da800ldm sp, {fp, sp, pc}
http://permalink.gmane.org/gmane.linux.linaro.devel/11653
v2 changes:
* Removed some unnecessary spaces [per Jess Juhl]
* Added return value for an error message [per Sascha Hauer]
* Reworked init scheme to use device tree late_initcall [per Sascha and Shawn]
* Moved imx6q and imx5 cpuidle functionality to existing files.
https://lkml.org/lkml/2012/5/1/363
v1 initial submission:
https://lkml.org/lkml/2012/4/16/644
Robert Lee (7):
ARM: imx: Modify IMX_IO_P2V macro
ARM: imx: Add comments to tzic_enable_waker()
ARM: imx: clean and consolidate imx5 suspend and idle code
ARM: imx: Enable imx53 low power idle
ARM: imx: Add common imx cpuidle init functionality.
ARM: imx: Add imx5 cpuidle
ARM: imx: Add imx6q cpuidle driver
arch/arm/mach-imx/clock-mx51-mx53.c |1 +
arch/arm/mach-imx/imx53-dt.c |1 +
arch/arm/mach-imx/mach-imx6q.c| 19 ++
arch/arm/mach-imx/mach-mx53_ard.c |1 +
arch/arm/mach-imx/mach-mx53_evk.c |1 +
arch/arm/mach-imx/mach-mx53_loco.c|1 +
arch/arm/mach-imx/mach-mx53_smd.c |1 +
arch/arm/mach-imx/mm-imx5.c | 25 ++-
arch/arm/mach-imx/pm-imx5.c | 103 +
arch/arm/plat-mxc/Makefile|1 +
arch/arm/plat-mxc/cpuidle.c | 80 ++
arch/arm/plat-mxc/include/mach/common.h |4 +-
arch/arm/plat-mxc/include/mach/cpuidle.h | 22 ++
arch/arm/plat-mxc/include/mach/hardware.h | 25 ---
arch/arm/plat-mxc/tzic.c |4 ++
15 files changed, 231 insertions(+), 58 deletions(-)
create mode 100644 arch/arm/plat-mxc/cpuidle.c
create mode 100644 arch/arm/plat-mxc/include/mach/cpuidle.h
--
1.7.10
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v4 1/7] ARM: imx: Modify IMX_IO_P2V macro
A change is needed in the IMX_IO_P2V macro to allow all imx5 platforms to use common definitions when accessing registers of peripherals on the AIPS2 bus. With this change, IMX_IO_P2V(MX50_AIPS2_BASE_ADDR) == IMX_IO_P2V(MX51_AIPS2_BASE_ADDR) == IMX_IO_P2V(MX53_AIPS2_BASE_ADDR). This change was tested for mapping conflicts using the iop2v script found at git://git.pengutronix.de/git/ukl/imx-iop2v.git and by performing a bootup of a default build using imx_v6_v7_defconfig on a imx51 babbage board and imx53 loco board. The comments were modified to reflect the output given by the script which shows the virtual address mappings. Signed-off-by: Robert Lee --- arch/arm/plat-mxc/include/mach/hardware.h | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/arch/arm/plat-mxc/include/mach/hardware.h b/arch/arm/plat-mxc/include/mach/hardware.h index 0630513..071afd0 100644 --- a/arch/arm/plat-mxc/include/mach/hardware.h +++ b/arch/arm/plat-mxc/include/mach/hardware.h @@ -50,7 +50,7 @@ * IO 0x0020+0x10 -> 0xf400+0x10 * mx21: * AIPI0x1000+0x10 -> 0xf440+0x10 - * SAHB1 0x8000+0x10 -> 0xf400+0x10 + * SAHB1 0x8000+0x10 -> 0xf500+0x10 * X_MEMC 0xdf00+0x004000 -> 0xf5f0+0x004000 * mx25: * AIPS1 0x43f0+0x10 -> 0xf530+0x10 @@ -58,47 +58,50 @@ * AVIC0x6800+0x10 -> 0xf580+0x10 * mx27: * AIPI0x1000+0x10 -> 0xf440+0x10 - * SAHB1 0x8000+0x10 -> 0xf400+0x10 + * SAHB1 0x8000+0x10 -> 0xf500+0x10 * X_MEMC 0xd800+0x10 -> 0xf5c0+0x10 * mx31: * AIPS1 0x43f0+0x10 -> 0xf530+0x10 * AIPS2 0x53f0+0x10 -> 0xf570+0x10 * AVIC0x6800+0x10 -> 0xf580+0x10 - * X_MEMC 0xb800+0x01 -> 0xf4c0+0x01 + * X_MEMC 0xb800+0x01 -> 0xf5c0+0x01 * SPBA0 0x5000+0x10 -> 0xf540+0x10 * mx35: * AIPS1 0x43f0+0x10 -> 0xf530+0x10 * AIPS2 0x53f0+0x10 -> 0xf570+0x10 * AVIC0x6800+0x10 -> 0xf580+0x10 - * X_MEMC 0xb800+0x01 -> 0xf4c0+0x01 + * X_MEMC 0xb800+0x01 -> 0xf5c0+0x01 * SPBA0 0x5000+0x10 -> 0xf540+0x10 * mx50: * TZIC0x0fffc000+0x004000 -> 0xf4bfc000+0x004000 - * SPBA0 0x5000+0x10 -> 0xf540+0x10 * AIPS1 0x53f0+0x10 -> 0xf570+0x10 + * SPBA0 0x5000+0x10 -> 0xf540+0x10 * AIPS2 0x63f0+0x10 -> 0xf530+0x10 * mx51: - * TZIC0xe000+0x004000 -> 0xf500+0x004000 + * TZIC0x0fffc000+0x004000 -> 0xf4bfc000+0x004000 * IRAM0x1ffe+0x02 -> 0xf4fe+0x02 + * DEBUG 0x6000+0x10 -> 0xf500+0x10 * SPBA0 0x7000+0x10 -> 0xf540+0x10 * AIPS1 0x73f0+0x10 -> 0xf570+0x10 - * AIPS2 0x83f0+0x10 -> 0xf430+0x10 + * AIPS2 0x83f0+0x10 -> 0xf530+0x10 * mx53: * TZIC0x0fffc000+0x004000 -> 0xf4bfc000+0x004000 + * DEBUG 0x4000+0x10 -> 0xf500+0x10 * SPBA0 0x5000+0x10 -> 0xf540+0x10 * AIPS1 0x53f0+0x10 -> 0xf570+0x10 * AIPS2 0x63f0+0x10 -> 0xf530+0x10 * mx6q: - * SCU 0x00a0+0x001000 -> 0xf400+0x001000 + * SCU 0x00a0+0x004000 -> 0xf400+0x004000 * CCM 0x020c4000+0x004000 -> 0xf42c4000+0x004000 - * ANATOP 0x020c8000+0x001000 -> 0xf42c8000+0x001000 + * ANATOP 0x020c8000+0x004000 -> 0xf42c8000+0x004000 * UART4 0x021f+0x004000 -> 0xf42f+0x004000 */ #define IMX_IO_P2V(x) ( \ - 0xf400 +\ + (((x) & 0x8000) >> 7) | \ + (0xf400 + \ (((x) & 0x5000) >> 6) + \ (((x) & 0x0b00) >> 4) + \ - (((x) & 0x000f))) + (((x) & 0x000f #define IMX_IO_ADDRESS(x) IOMEM(IMX_IO_P2V(x)) -- 1.7.10 _
[PATCH v4 6/7] ARM: imx: Add imx5 cpuidle
Add cpuidle driver for imx5 platform.
Signed-off-by: Robert Lee
---
arch/arm/mach-imx/pm-imx5.c | 44 ---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index 6e62d79..966c71b 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -12,10 +12,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include "crm-regs-imx5.h"
@@ -134,12 +136,48 @@ static const struct platform_suspend_ops mx5_suspend_ops
= {
.enter = mx5_suspend_enter,
};
-static void imx5_pm_idle(void)
+static inline int imx5_cpu_do_idle(void)
{
- if (likely(!tzic_enable_wake()))
+ int ret = tzic_enable_wake();
+
+ if (likely(!ret))
cpu_do_idle();
+
+ return ret;
}
+static void imx5_pm_idle(void)
+{
+ imx5_cpu_do_idle();
+}
+
+static int imx5_cpuidle_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int idx)
+{
+ int ret;
+
+ ret = imx5_cpu_do_idle();
+ if (ret < 0)
+ return ret;
+
+ return idx;
+}
+
+static struct cpuidle_driver imx5_cpuidle_driver = {
+ .name = "imx5_cpuidle",
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
+ .states[0] = {
+ .enter = imx5_cpuidle_enter,
+ .exit_latency = 2,
+ .target_residency = 1,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = "IMX5 SRPG",
+ .desc = "CPU state retained,powered off",
+ },
+ .state_count= 1,
+};
+
int __init imx5_pm_init(void)
{
int ret;
@@ -160,5 +198,5 @@ int __init imx5_pm_init(void)
/* Set the registers to the default cpu idle state. */
mx5_cpu_lp_set(IMX5_DEFAULT_CPU_IDLE_STATE);
- return 0;
+ return imx_cpuidle_init(&imx5_cpuidle_driver);
}
--
1.7.10
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v4 4/7] ARM: imx: Enable imx53 low power idle
Add various functionality needed to enable a imx53 low power idle
state. This includes adding the imx53 gpc_dvfs clock and making a
common imx5_late_init function and initializing all imx53
MACHINE_STATE late_init calls to imx5_late_init.
Signed-off-by: Robert Lee
---
arch/arm/mach-imx/clock-mx51-mx53.c |1 +
arch/arm/mach-imx/imx53-dt.c|1 +
arch/arm/mach-imx/mach-mx53_ard.c |1 +
arch/arm/mach-imx/mach-mx53_evk.c |1 +
arch/arm/mach-imx/mach-mx53_loco.c |1 +
arch/arm/mach-imx/mach-mx53_smd.c |1 +
arch/arm/mach-imx/mm-imx5.c |7 ++-
arch/arm/plat-mxc/include/mach/common.h |1 +
8 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clock-mx51-mx53.c
b/arch/arm/mach-imx/clock-mx51-mx53.c
index 0847050..decedc6 100644
--- a/arch/arm/mach-imx/clock-mx51-mx53.c
+++ b/arch/arm/mach-imx/clock-mx51-mx53.c
@@ -1529,6 +1529,7 @@ static struct clk_lookup mx53_lookups[] = {
_REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk)
_REGISTER_CLOCK("imx-ssi.2", NULL, ssi3_clk)
_REGISTER_CLOCK("imx-keypad", NULL, dummy_clk)
+ _REGISTER_CLOCK(NULL, "gpc_dvfs", gpc_dvfs_clk)
_REGISTER_CLOCK("pata_imx", NULL, pata_clk)
_REGISTER_CLOCK("imx53-ahci.0", "ahci", sata_clk)
_REGISTER_CLOCK("imx53-ahci.0", "ahci_phy", ahci_phy_clk)
diff --git a/arch/arm/mach-imx/imx53-dt.c b/arch/arm/mach-imx/imx53-dt.c
index 4172279..39d2ca7 100644
--- a/arch/arm/mach-imx/imx53-dt.c
+++ b/arch/arm/mach-imx/imx53-dt.c
@@ -125,6 +125,7 @@ DT_MACHINE_START(IMX53_DT, "Freescale i.MX53 (Device Tree
Support)")
.handle_irq = imx53_handle_irq,
.timer = &imx53_timer,
.init_machine = imx53_dt_init,
+ .init_late = imx5_init_late,
.dt_compat = imx53_dt_board_compat,
.restart= mxc_restart,
MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx53_ard.c
b/arch/arm/mach-imx/mach-mx53_ard.c
index 0564198..afb3d14 100644
--- a/arch/arm/mach-imx/mach-mx53_ard.c
+++ b/arch/arm/mach-imx/mach-mx53_ard.c
@@ -266,5 +266,6 @@ MACHINE_START(MX53_ARD, "Freescale MX53 ARD Board")
.handle_irq = imx53_handle_irq,
.timer = &mx53_ard_timer,
.init_machine = mx53_ard_board_init,
+ .init_late = imx5_init_late,
.restart= mxc_restart,
MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx53_evk.c
b/arch/arm/mach-imx/mach-mx53_evk.c
index 5a72188..929969f 100644
--- a/arch/arm/mach-imx/mach-mx53_evk.c
+++ b/arch/arm/mach-imx/mach-mx53_evk.c
@@ -174,5 +174,6 @@ MACHINE_START(MX53_EVK, "Freescale MX53 EVK Board")
.handle_irq = imx53_handle_irq,
.timer = &mx53_evk_timer,
.init_machine = mx53_evk_board_init,
+ .init_late = imx5_init_late,
.restart= mxc_restart,
MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx53_loco.c
b/arch/arm/mach-imx/mach-mx53_loco.c
index 37f67ca..bc5012b 100644
--- a/arch/arm/mach-imx/mach-mx53_loco.c
+++ b/arch/arm/mach-imx/mach-mx53_loco.c
@@ -316,5 +316,6 @@ MACHINE_START(MX53_LOCO, "Freescale MX53 LOCO Board")
.handle_irq = imx53_handle_irq,
.timer = &mx53_loco_timer,
.init_machine = mx53_loco_board_init,
+ .init_late = imx5_init_late,
.restart= mxc_restart,
MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx53_smd.c
b/arch/arm/mach-imx/mach-mx53_smd.c
index 8e972c5..568190b 100644
--- a/arch/arm/mach-imx/mach-mx53_smd.c
+++ b/arch/arm/mach-imx/mach-mx53_smd.c
@@ -163,5 +163,6 @@ MACHINE_START(MX53_SMD, "Freescale MX53 SMD Board")
.handle_irq = imx53_handle_irq,
.timer = &mx53_smd_timer,
.init_machine = mx53_smd_board_init,
+ .init_late = imx5_init_late,
.restart= mxc_restart,
MACHINE_END
diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c
index bb38747..7740739 100644
--- a/arch/arm/mach-imx/mm-imx5.c
+++ b/arch/arm/mach-imx/mm-imx5.c
@@ -216,8 +216,13 @@ void __init imx53_soc_init(void)
ARRAY_SIZE(imx53_audmux_res));
}
+void __init imx5_init_late(void)
+{
+ imx5_pm_init();
+}
+
void __init imx51_init_late(void)
{
mx51_neon_fixup();
- imx5_pm_init();
+ imx5_init_late();
}
diff --git a/arch/arm/plat-mxc/include/mach/common.h
b/arch/arm/plat-mxc/include/mach/common.h
index 5660e1e..6d2e910 100644
--- a/arch/arm/plat-mxc/include/mach/common.h
+++ b/arch/arm/plat-mxc/include/mach/common.h
@@ -54,6 +54,7 @@ extern void imx50_soc_init(void);
extern void imx51_soc_init(void);
extern void imx53_soc_init(void);
extern void imx51_init_late(void);
+extern void imx5_init_late(void);
extern void epit_timer_init(struct clk *timer_clk, void __iomem *base, int
irq);
extern void mxc_timer_init(struct clk *timer_clk, void __iomem *, int);
extern int mx1_clocks_init(unsigned long fref);
--
1.7.10
_
Re: [RFC PATCH v1] AudiVal (Audio Validation Suite for Linux)
On Tue, May 15, 2012 at 4:24 PM, Tom Gall wrote: > HI Paul, > > On Tue, May 15, 2012 at 4:14 PM, Paul Larson > wrote: > > Cool, does this replace the existing e2daudiotest I guess? > > Please consider it as complementary. > > Ah, I see after looking at it a bit more. This one isn't completely automated and requires someone to listen to the sound :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Building a SINGLE driver file - A tip.
Hello All Just discovered something, wanted to share, might be that many out there will be knowing this, for the unknowns sharing this: We do few source file change and then end up building the entire stuff using "make" command. Mid way through the build we see that a single annoying COMPILE ERROR and see its such a waste of time. So the ideal thing is to just compile and link only the changed file which will be quick and rest assured FULL the build will succeed. So here's how it is to be done: In my below example I am building the Sensor file which is in the path, kernel/drivers/hwmon: *The build command is:* make -C ../out/target/product/snowball/obj/kernel/ SUBDIRS=drivers/hwmon ARCH=arm CROSS_COMPILE=arm-eabi- *Replace the "drivers/hwmon" to your location where the file you modified is present and it builds.* For eg: venkatr@build1:~/snowball_board_branch_0.0.3/kernel$ vim drivers/hwmon/lsm303dlh_m.c venkatr@build1:~/snowball_board_branch_0.0.3/kernel$ make -C ../out/target/product/snowball/obj/kernel/ SUBDIRS=drivers/hwmon ARCH=arm CROSS_COMPILE=arm-eabi- make: Entering directory `/u/home01/venkatr/snowball_board_branch_0.0.3/out/target/product/snowball/obj/kernel' make -C /u/home01/venkatr/snowball_board_branch_0.0.3/kernel O=/u/home01/venkatr/snowball_board_branch_0.0.3/out/target/product/snowball/obj/kernel/. CC drivers/hwmon/lsm303dlh_m.o LD drivers/hwmon/built-in.o Building modules, stage 2. MODPOST 0 modules make: Leaving directory `/u/home01/venkatr/snowball_board_branch_0.0.3/out/target/product/snowball/obj/kernel' venkatr@build1:~/snowball_board_branch_0.0.3/kernel$ BR, Venkat. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v1] AudiVal (Audio Validation Suite for Linux)
On 16 May 2012 02:44, Paul Larson wrote:
> Cool, does this replace the existing e2daudiotest I guess?
This script can serve as a unified interface to various audio tests that we
are developing.
Kurt (adding in CC) has suggested to plug-in e2eaudiotest into this as well.
Also, has it already been shown to work on all of the listed board?
>
It has been tested on Panda, imx6, Origen as of now, and the script works
as expected.
However, the tests obviously fail where audio recording is not supported by
underlying kernel.
>
> On Tue, May 15, 2012 at 9:00 AM, Harsh Prateek Bora > wrote:
>
>>AudiVal (Audio Validation Suite for Linux)
>>
>> This is an attempt to automate and integrate various audio related tests
>> which
>> can help validate audio on various boards supported by Linaro. Motivation
>> for
>> this project comes from various audio tests listed at:
>> https://wiki.linaro.org/TomGall/LinaroAudioFeatureIndex
>>
>> The git repo for this project can be cloned from:
>> git://git.linaro.org/people/harshbora/audival.git
>>
>> Various files required by this script are available in the git repo.
>>
>> Requesting all to test this script on various boards that you may have
>> access
>> to and share feedback to make it better.
>>
>> TODO: Add tests for Audio over USB, Bluetooth.
>>
>> Signed-off-by: Harsh Prateek Bora
>>
>> diff --git a/AudiVal.py b/AudiVal.py
>> new file mode 100755
>> index 000..7d56c4e
>> --- /dev/null
>> +++ b/AudiVal.py
>> @@ -0,0 +1,247 @@
>> +#!/usr/bin/env python
>> +#
>> +# Audival : Audio Validation Suite for Linux.
>> +#
>> +# Author: Harsh Prateek Bora
>> +#
>> +#
>> +
>> +import os
>> +import sys
>> +import getopt
>> +from subprocess import * # for calling external programs
>> +import commands # deprecated since python 2.6, Python 3.0 uses subprocess
>> +
>> +def usage():
>> +print "="
>> +print "AudiVal: Audio Validation Suite for Linux"
>> +print "="
>> +print "Usage:"
>> +print sys.argv[0], "[--check-info]"
>> +print
>> +print "Supported HW: PandaBoard (ES), BeagleBoard (XM), i.MX53,
>> i.MX6, Origen, Snowball"
>> +sys.exit(1)
>> +
>> +SpeakerJack = {
>> +'GenuineIntel': 'Analog',
>> +'Panda':'Headset',
>> +'Beagle': 'TWL4030',
>> +'i.MX53': 'HiFi',
>> +'i.MX6':'HiFi',
>> +'ORIGEN': 'Pri_Dai',
>> +'Snowball': 'Headset'
>> +}
>> +
>> +MicJack = {
>> +'GenuineIntel': 'Analog',
>> +'Panda':'Headset', # not sure though, arecord doesnt
>> work for me!
>> +'Beagle': 'TWL4030',
>> +'i.MX53': 'HiFi',
>> +'i.MX6':'HiFi',
>> +'ORIGEN': 'Pri_Dai',
>> +'Snowball': 'Headset'
>> +}
>> +
>> +# As and when HDMI out/in device string differs, we'll need 2
>> dictionaries.
>> +HDMI_Audio = {
>> +'GenuineIntel': 'HDMI',
>> +'Panda':'HDMI',
>> +'Beagle': 'HDMI',
>> +'i.MX53': 'HDMI',
>> +'i.MX6':'HDMI', # audio out only supported, audio in not
>> supported.
>> +'ORIGEN': 'HDMI',
>> +'Snowball': 'hdmi' # odd one, lowercase
>> +}
>> +
>> +Audio_Devices = {
>> +'playback':'aplay-l.log',
>> +'capture': 'arecord-l.log'
>> +}
>> +
>> +def get_device_list(logfile):
>> +fobj = open(logfile)
>> +return fobj
>> +
>> +def get_card_device_info_by_name(devicestr, fobj):
>> +"""Helper routine to get card, device number by interface name"""
>> +optxt = fobj.readlines()
>> +card = ""
>> +device = ""
>> +for line in optxt:
>> +if devicestr in line:
>> +cardtext, colon, text = line.partition(':')
>> +pre, sep, card = cardtext.partition(' ')
>> +devtext, colon, text = text.partition(':')
>> +pre, sep, device = devtext.partition('device ')
>> +break
>> +hwstr = 'plughw:' + card + ',' + device
>> +if card is "" and device is "":
>> +return None
>> +return hwstr
>> +
>> +def speaker_test_audio_jack(board):
>> +fobj = get_device_list(Audio_Devices['playback'])
>> +print "speaker-test over audio jack .."
>> +headset_jack_id = get_card_device_info_by_name(SpeakerJack[board],
>> fobj)
>> +fobj.close()
>> +if headset_jack_id is None:
>> +print "No Audio Jack found !"
>> +return
>> +call("date > speaker-test-jack.log", shell=True)
>> +cmdstr = "speaker-test -D " + headset_jack_id + " -t s -c 2 -l 1 >
>> speaker-test-jack.log 2>&1"
>> +call(cmdstr, shell=True)
>> +print "If you heard beeps from left and right speaker, test passed."
>> +
>> +def aplay_over_jack(board):
>> +fobj = get_device_list(Audio_Devices['playback'])
>> +headset_jack_id = get_card_device_info_by_name(SpeakerJack[board],
>> fobj)
>> +print "Testi
Re: [RFC PATCH v1] AudiVal (Audio Validation Suite for Linux)
On 16 May 2012 09:38, Paul Larson wrote: > On Tue, May 15, 2012 at 4:24 PM, Tom Gall wrote: > >> HI Paul, >> >> On Tue, May 15, 2012 at 4:14 PM, Paul Larson >> wrote: >> > Cool, does this replace the existing e2daudiotest I guess? >> >> Please consider it as complementary. >> >> Ah, I see after looking at it a bit more. This one isn't completely > automated and requires someone to listen to the sound :) > Yes, Its the initial phase and therefore will evolve with time as required. We may want to plug-in e2eaudiotest and others if already available. As of now, it frees the user from finding out the card, device info for each audio playback/recording device on supported hardware and can help in identify issues where audio is almost ok, but not truly perfect (like choppy audio). Un-attended tests may treat imperfect audio as bad as no audio. I hope I am able to convey what I intend to do so. thanks, Harsh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
