[ACTIVITY] Graphics weekly status report - wk46-47 (20111114-20111125)
Status report in detail - contains the delivered content for 11.11 and the plans for 11.12 as of now: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport Last weekly meeting notes: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-11-23 Highlights: - Based on the meeting last week with DX side: no changed lately on NUX. openGLES code has been merged, and believed to be functional and working. At the moment doing more testing on NUX. There is a shift in DX to accept branches after more testing, much of which is automated. + In the future there is more need for testing for functional verification and also regression testing + Specification related to the tests was requested from DX. Note that the tests for the graphics stack have not been decided yet. + For the Linaro side what is important is that DX team want to have a test for every major feature/release related to openGLES. New features should be accompanied by test code, covering the functionality as we well as regression cases. + Admittedly there is still a definition pending on DX side about what coverage to provide, not every submission will need a new test necessarily. This is still being decided at the DX team level, and they will communicate with Linaro on the process (still undefined on wk47) o This delay in communicating the test specification can potentially cause delays on Graphics WG - Daily benchmarks running on LAVA: + http://validation.linaro.org/lava-server/dashboard/streams/anonymous/linaro-gfx-daily/bundles/ + Dealing with some final issues: Having some boot issues, probably kernel related, which will need to be cleared this week - Starting in 11.12 to analyse the power management work for Graphics - Moved all Launchpad projects for Graphics WG to use trunk as their active series of development Any questions or clarification needed? Please let me know. -- Ilias Biris ilias.bi...@linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris 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: [Launchpad-users] launchpad: ddeb packages in ppa problem
On Wednesday 09 November 2011 19:13:02 Riku Voipio wrote: Hi, I got the following errors from my recent uploads to linaro-maintainers/staging-overlay ppa: Rejected: Orphaned debug packages: zlib1g-udeb-dbgsym 1:1.2.3.4.dfsg-3ubuntu3linaro1 (i386) So it seems ddebs have been enabled (thanks!), but seems broken - I didn't do anything udeb related while packaging, and if udebs are being dropped automatically, seems so should be done to the udebs dbgsym package. This is bug https://bugs.launchpad.net/launchpad/+bug/886452 and it's scheduled to be fixed imminently. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Multimedia WG weekly status report - wk46-47.2011 (20111114-20111125)
Status with details on both the delivered content for 11.11 and the plans for 11.12: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Last weekly meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-11-22 Highlights - Codecs + Created a wiki page to collect the status of NEON optimisation of different codecs: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/NeonStatus. Feedback is welcome as well as adding your favourite libraries! - For LJT: + scoped out use across main, universe and multiverse of libjpeg62, libjpeg8 and -dev + ppa tom-gall/libjpeg-turbo updated with libjpeg8 compat version of libjpeg-turbo + all packages that use libjpeg-dev pushed to ppa (31 pending builds yet, 89 successful 0 failures) - UMM + Completed the xf86nouveau development of dri2video support. + Setup CI build to test CMA on snowball: https://ci.linaro.org/jenkins/view/All/job/linux-linaro-snowball-cma-test/ + Reworked debugfs and trace patches for CMA v17 Comments, clarifications needed? Please let me know! Best regards, -- Ilias Biris ilias.bi...@linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris 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: Explanation of the different Ubuntu images?
On 11/28/2011 07:20 AM, Jon Medhurst (Tixy) wrote: Does anyone know of a web-site or wiki page which explains the difference between our different Ununtu image types, i.e. developer, nano, alip, server, ubuntu-desktop. I've a fair idea myself what these are, (apart from server), but I'm looking for an existing document I can reference. I just discovered we do a terrible job of doing this. Its buried down in a page you are unlikely to hit and was done before the server image existed: https://wiki.linaro.org/Boards/Overo/Setup I'll add this as TODO for the on-going wiki work. -andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Explanation of the different Ubuntu images?
At one time we had links to the explanations as part of every release. Looking at https://wiki.linaro.org/Cycles/YYMM/Release pages it looks as if that information was removed. It does seem like a good idea to include the explanations just so interested people can see more detain about the available images. On Mon, Nov 28, 2011 at 10:21 AM, Andy Doan andy.d...@linaro.org wrote: On 11/28/2011 07:20 AM, Jon Medhurst (Tixy) wrote: Does anyone know of a web-site or wiki page which explains the difference between our different Ununtu image types, i.e. developer, nano, alip, server, ubuntu-desktop. I've a fair idea myself what these are, (apart from server), but I'm looking for an existing document I can reference. I just discovered we do a terrible job of doing this. Its buried down in a page you are unlikely to hit and was done before the server image existed: https://wiki.linaro.org/Boards/Overo/Setup I'll add this as TODO for the on-going wiki work. -andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Regards, Tom We want great men who, when fortune frowns will not be discouraged. - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Libjpeg-turbo rebuild status
Hi Matthias, Over the Thanksgiving holiday the compile-o-rama complete for all the packages from the main and universe archives that had deps on libjpeg-dev. The results of the build can be found in my libjpeg-turbo ppa: https://launchpad.net/~tom-gall/+archive/libjpeg-turbo/+packages In summary, 114 packages were rebuilt against the libjpeg-turbo's version of -dev. One package vtk resulted in the only 2 failures that have been experienced. One failure on x86, and one on x86_64. Both failures were caused not by problems with libjpeg-turbo but rather with poor build time deps specified in the package. This can be witnessed in the logs: https://launchpadlibrarian.net/85691287/buildlog_ubuntu-precise-amd64.vtk_5.6.1-7~linaro1_FAILEDTOBUILD.txt.gz https://launchpadlibrarian.net/85716285/buildlog_ubuntu-precise-i386.vtk_5.6.1-7~linaro1_FAILEDTOBUILD.txt.gz I have also updated the raw performance numbers for libjpeg-turbo in our wiki. (I haven't updated the graphs yet) https://wiki.linaro.org/TomGall/LibJpeg8 All raw performance numbers are now from oneiric. I've also included numbers from a 3.3Gz i5-2500 to the mix as well numbers taken on the Quickstart board with the lib instructed to not use NEON. With SIMD for intel/arm environment performance is substantially better in all cases. With NEON off in libjpeg-turbo, performance is at least equal and in some cases better than libjpeg8. All that said, what is the next step? -- Regards, Tom We want great men who, when fortune frowns will not be discouraged. - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 0/5] OMAP4: cache fixes for 4460
From: Mans Rullgard [mailto:mans.rullg...@linaro.org] Sent: Sunday, November 27, 2011 6:26 PM Hi, By the way, do you know whether it is safe to use SCU Speculative linefills with Cortex-A9 r2pX and PL310 r3pX? http://infocenter.arm.com/help/topic/com.arm.doc.ddi0407f/BABEBFBH.html As a quick and dirty test, it can be enabled in 'arch/arm/kernel/smp_scu.c' by just setting extra (1 3) bit in SCU Control Register from 'scu_enable' function. snip Be careful. That chip has PL310 r3p0 so it's affected by erratum 729806, Speculative reads from the Cortex-A9 MPCore processor can cause deadlock. For OMAP4's it should be OK as long as other necessary errata work arounds are activated in code today. However, As Mans points out other partner chips might have an issue. Your benchmark results are interesting. I did have a couple threads with an expert on this point and your result matches. Impact depends on data set size of use case and configured speed of pl310 logic. It was explained that when 1 processor requests shared data (all Linux-SMP memory is marked with S-bit), the SCU can signal a hint to PL310 to start a parallel L2-tag lookup while SCU-snoop-tag is checked (to see if coherency L1-cache-2-cache transfer needs to happen). In case of a snoop-cache-miss, you are now 2-3 cycles ahead of the game into the PL310 cache-tag lookup. If the data is in other processor you would have burned some power with needless lookup and perhaps (depending on resource load) delayed some valid request. Regard, Richard W. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
End to end audio test - initial drop
Hi everyone, Last week I did an initial drop of the end to end audio test we have been discussing. The idea is fairly simple, play a sine wave and test the audio stack by sampling/testing the sine back in via loopback cable. The app is called testfreq and is driven by a script called e2eaudiotest. It opens and configures the audio device, takes a sample and then does a discrete fourier transformation to find the frequency using the fftw3 library. The test script driver uses speaker-test to play a sine wave at A 440, which for now is the test frequency. It's still basic at this point, but it does work on my system. There is a lot of additional things I'd like to do, initial stack configuration, passing in the device, passing the test frequency, doing more auto detection, clean up the code, etc, but I wanted to start getting feedback. Any and all would be appreciated. Have a look, and if you have a loopback cable, give it a spin: http://git.linaro.org/gitweb?p=people/kurt-r-taylor/e2eaudiotest.git You can also read more about it and check my progress here: https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmwg-e2eaudiotesting-basic Enjoy! -- Kurt Taylor (irc krtaylor) Linaro Multimedia Linaro.org http://www.linaro.org/* **│ *Open source software for ARM SoCs Follow *Linaro: *Facebook http://www.facebook.com/pages/Linaro | Twitterhttp://twitter.com/#%21/linaroorg| Blog http://www.linaro.org/linaro-blog/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: End to end audio test - initial drop
On 28 November 2011 20:01, Kurt Taylor kurt.tay...@linaro.org wrote: Hi everyone, Last week I did an initial drop of the end to end audio test we have been discussing. The idea is fairly simple, play a sine wave and test the audio stack by sampling/testing the sine back in via loopback cable. The app is called testfreq and is driven by a script called e2eaudiotest. It opens and configures the audio device, takes a sample and then does a discrete fourier transformation to find the frequency using the fftw3 library. The test script driver uses speaker-test to play a sine wave at A 440, which for now is the test frequency. It's still basic at this point, but it does work on my system. There is a lot of additional things I'd like to do, initial stack configuration, passing in the device, passing the test frequency, doing more auto detection, clean up the code, etc, but I wanted to start getting feedback. Any and all would be appreciated. Have a look, and if you have a loopback cable, give it a spin: http://git.linaro.org/gitweb?p=people/kurt-r-taylor/e2eaudiotest.git You can also read more about it and check my progress here: https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmwg-e2eaudiotesting-basic Looks pretty good for a low level test. I'm not sure how well it'll work with Android. Would you be able to put together an Android App that used MediaPlayer and MediaRecorder to accomplish the same thing? It should like this test may be a good candidate for kernel regression testing. Enjoy! -- Kurt Taylor (irc krtaylor) Linaro Multimedia Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 1/2] power: Charger-Manager: add initial Charger-Manager driver
On Thu, Nov 17, 2011 at 6:13 PM, Donggeun Kim dg77@samsung.com wrote:
Because battery health monitoring should be done even when suspended,
it needs to wake up and suspend periodically. Thus, userspace battery
monitoring may incur too much overhead; every device and task is woken
up periodically. Charger Manager uses suspend-again to provide
in-suspend monitoring.
This patch allows to monitor battery health in-suspend state.
Signed-off-by: Donggeun Kim dg77@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/power/charger-manager.txt | 150 ++
drivers/power/Kconfig | 9 +
drivers/power/Makefile | 1 +
drivers/power/charger-manager.c | 771
+++
include/linux/power/charger-manager.h | 131 ++
5 files changed, 1062 insertions(+), 0 deletions(-)
create mode 100644 Documentation/power/charger-manager.txt
create mode 100644 drivers/power/charger-manager.c
create mode 100644 include/linux/power/charger-manager.h
diff --git a/Documentation/power/charger-manager.txt
b/Documentation/power/charger-manager.txt
new file mode 100644
index 000..99630e5
--- /dev/null
+++ b/Documentation/power/charger-manager.txt
@@ -0,0 +1,150 @@
+Charger Manager
+ (C) 2011 MyungJoo Ham myungjoo@samsung.com, GPL
+
+Charger Manager provides in-kernel battery charger management that
+requires temperature monitoring during suspend-to-RAM state
+and where each battery may have multiple chargers attached and the userland
+wants to look at the aggregated information of the multiple chargers.
+
+Charger Manager is a platform_driver with power-supply-class entries.
+An instance of Charger Manager (a platform-device created with
Charger-Manager)
+represents an independent battery with chargers. If there are multiple
+batteries with their own chargers acting independently in a system,
+the system may need multiple instances of Charger Manager.
+
+1. Introduction
+===
+
+Charger Manager supports the following:
+
+* Support for multiple chargers (e.g., a device with USB, AC, and solar
panels)
+ A system may have multiple chargers (or power sources) and some of
+ they may be activated at the same time. Each charger may have its
+ own power-supply-class and each power-supply-class can provide
+ different information about the battery status. This framework
+ aggregates charger-related information from multiple sources and
+ shows combined information as a single power-supply-class.
+
+* Support for in suspend-to-RAM polling (with suspend_again callback)
+ While the battery is being charged and the system is in
suspend-to-RAM,
+ we may need to monitor the battery health by looking at the ambient or
+ battery temperature. We can accomplish this by waking up the system
+ periodically. However, such a method wakes up devices unncessary for
+ monitoring the battery health and tasks, and user processes that are
+ supposed to be kept suspended. That, in turn, incurs unnecessary power
+ consumption and slow down charging process. Or even, such peak power
+ consumption can stop chargers in the middle of charging
+ (external power input device power consumption), which not
+ only affects the charging time, but the lifespan of the battery.
+
+ Charger Manager provides a function cm_suspend_again that can be
+ used as suspend_again callback of platform_suspend_ops. If the
platform
+ requires tasks other than cm_suspend_again, it may implement its own
+ suspend_again callback that calls cm_suspend_again in the middle.
+ Normally, the platform will need to resume and suspend some devices
+ that are used by Charger Manager.
+
+2. Global Charger-Manager Data related with suspend_again
+
+In order to setup Charger Manager with suspend-again feature
+(in-suspend monitoring), the user should provide charger_global_desc
+with setup_charger_manager(struct charger_global_desc *).
+This charger_global_desc data for in-suspend monitoring is global
+as the name suggests. Thus, the user needs to provide only once even
+if there are multiple batteries. If there are multiple batteries, the
+multiple instances of Charger Manager share the same charger_global_desc
+and it will manage in-suspend monitoring for all instances of Charger
Manager.
+
+The user needs to provide all the three entries properly in order to activate
+in-suspend monitoring:
+
+struct charger_global_desc {
+
+char *rtc;
+ : The name of rtc (e.g., rtc0) used to wakeup the system from
+ suspend for Charger Manager. The alarm interrupt (AIE) of the rtc
+ should be able to wake up the system
Re: [RFC PATCH 1/2] power: Charger-Manager: add initial Charger-Manager driver
On Tue, Nov 29, 2011 at 1:41 PM, Haojian Zhuang
haojian.zhu...@gmail.com wrote:
On Thu, Nov 17, 2011 at 6:13 PM, Donggeun Kim dg77@samsung.com wrote:
Because battery health monitoring should be done even when suspended,
it needs to wake up and suspend periodically. Thus, userspace battery
monitoring may incur too much overhead; every device and task is woken
up periodically. Charger Manager uses suspend-again to provide
in-suspend monitoring.
This patch allows to monitor battery health in-suspend state.
[]
+/**
+ * cm_setup_timer - For in-suspend monitoring setup wakeup alarm
+ * for suspend_again.
+ *
+ * Returns true if the alarm is set for Charger Manager to use.
+ * Returns false if
+ * cm_setup_timer fails to set an alarm,
+ * cm_setup_timer does not need to set an alarm for Charger Manager,
+ * or an alarm previously configured is to be used.
+ */
+static bool cm_setup_timer(void)
+{
+ struct charger_manager *cm;
+ unsigned int wakeup_ms = UINT_MAX;
+ bool ret = false;
+
+ mutex_lock(cm_list_mtx);
+
+ list_for_each_entry(cm, cm_list, entry) {
+ /* Skip if polling is not required for this CM */
+ if (!is_polling_required(cm) !cm-emergency_stop)
+ continue;
+ if (cm-desc-polling_interval_ms == 0)
+ continue;
+ CM_MIN_VALID(wakeup_ms, cm-desc-polling_interval_ms);
+ }
+
+ mutex_unlock(cm_list_mtx);
+
+ if (wakeup_ms UINT_MAX wakeup_ms 0) {
+ pr_info(Charger Manager wakeup timer: %u ms.\n, wakeup_ms);
+ if (rtc_dev) {
+ struct rtc_wkalrm tmp;
+ unsigned long time, now;
+ unsigned long add = DIV_ROUND_UP(wakeup_ms, 1000);
+
+ /*
+ * Set alarm with the polling interval (wakeup_ms)
+ * except when rtc_wkalarm_save comes first.
+ * However, the alarm time should be NOW +
+ * CM_RTC_SMALL or later.
+ */
+ tmp.enabled = 1;
+ rtc_read_time(rtc_dev, tmp.time);
+ rtc_tm_to_time(tmp.time, now);
+ if (add CM_RTC_SMALL)
+ add = CM_RTC_SMALL;
+ time = now + add;
+
+ ret = true;
+
+ if (rtc_wkalarm_save.enabled rtc_wkalarm_save_
+ rtc_wkalarm_save_ time) {
+ if (rtc_wkalarm_save_ now + CM_RTC_SMALL)
+ time = now + CM_RTC_SMALL;
+ else
+ time = rtc_wkalarm_save_;
+
+ /* The timer is not appointed by CM */
+ ret = false;
+ }
+
+ pr_info(Waking up after %lu secs.\n,
+ time - now);
+
+ rtc_time_to_tm(time, tmp.time);
+ rtc_set_alarm(rtc_dev, tmp);
+ cm_suspend_duration_ms += wakeup_ms;
+ return ret;
+ }
+ }
+
+ if (rtc_dev)
+ rtc_set_alarm(rtc_dev, rtc_wkalarm_save);
+ return false;
+}
+
[]
+
+static int cm_suspend_prepare(struct device *dev)
+{
+ struct platform_device *pdev = container_of(dev, struct
platform_device,
+ dev);
+ struct charger_manager *cm = platform_get_drvdata(pdev);
+
+ if (!cm_suspended) {
+ if (rtc_dev) {
+ struct rtc_time tmp;
+ unsigned long now;
+
+ rtc_read_alarm(rtc_dev, rtc_wkalarm_save);
+ rtc_read_time(rtc_dev, tmp);
+
+ if (rtc_wkalarm_save.enabled) {
+ rtc_tm_to_time(rtc_wkalarm_save.time,
+ rtc_wkalarm_save_);
+ rtc_tm_to_time(tmp, now);
+ if (now rtc_wkalarm_save_)
+ rtc_wkalarm_save_ = 0;
+ } else {
+ rtc_wkalarm_save_ = 0;
+ }
+ }
+ cm_suspended = true;
+ }
Donggeun,
I think that this patch is good for saving energy for charging while
suspend. I think that this driver also works under android. I have
some concerns on rtc wakeup.
As we know, RTC event doesn't link to timer events in kernel. But
Android did. Android transfered timer event to rtc event while it
suspend. So it
Re: [RFC PATCH 1/2] power: Charger-Manager: add initial Charger-Manager driver
On Tue, Nov 29, 2011 at 1:00 PM, MyungJoo Ham myungjoo@samsung.com wrote: On Tue, Nov 29, 2011 at 1:41 PM, Haojian Zhuang haojian.zhu...@gmail.com wrote: On Thu, Nov 17, 2011 at 6:13 PM, Donggeun Kim dg77@samsung.com wrote: Because battery health monitoring should be done even when suspended, it needs to wake up and suspend periodically. Thus, userspace battery monitoring may incur too much overhead; every device and task is woken up periodically. Charger Manager uses suspend-again to provide in-suspend monitoring. This patch allows to monitor battery health in-suspend state. Donggeun, I think that this patch is good for saving energy for charging while suspend. I think that this driver also works under android. I have some concerns on rtc wakeup. As we know, RTC event doesn't link to timer events in kernel. But Android did. Android transfered timer event to rtc event while it suspend. So it will occupy one rtc device. Whatever the device is phone or tablet, it may cost another rtc device if it wants to implement power-up alarm feature. If we want to support the charger manager feature, we have to add another rtc device. I think that it's very hard to find any current platform with three rtc devices. How about implement the similar mechanism like android? Charger manager can register wakeup event into alarm mechanism like android. And we only need two rtc devices. Loop more guys: list-arm-kernel linaro. Thanks Haojianbelow patch and comment whether Hello Haojian, No, we do not need to add another RTC device due to the usage of RTC alarm from another device drivers or processes. We can share an RTC device with others as long as others do not set RTC alarm in the suspend-to-RAM context (specifically from prepare ops to complete ops). The reason why we have created cm_setup_timer() looking that awfully complex is to let it coexist with other RTC alarm events and share the precious RTC device. Anyway, why do we even need two RTC devices in general? If we want the device to implement power-up alarm, we need two rtc devices. Let me use an example in Android system. 1. Application set time interval to receive mail after 10 minutes. 2. Android suspend and it convert the timer event into RTC event. 3. Battery is removed. After a while, we put the battery back. The battery insertion won't trigger phone up since it's depend on custom scenario. 4. 10 minutes interval past and phone will be powered up since rtc wakeup. Absolutely it's incorrect. We only need a resume event, not a power up event. If we have two rtc devices, one is external rtc and the other is contained in SoC. While battery removed, only SoC rtc will lost power and external rtc can keep status for a long time. So let's check the item #4. 4. Since status is lost in SoC rtc, system won't wakeup while 10 minutes interval past. If the RTC subsystem supports registering multiple alarm events, that'd be nice and will make this one simpler as well; however, we do not have it here for now. We save previous RTC alarm if the configuration data says so (rtc_wkalarm_save.enabled) and previously set alarm is later than the current alarm and restore the RTC alarm value at wakeup. If the previously set RTC alarm is earlier than the timer setup of Charger Manager, we do not load the alarm value of Charger Manager and let the previously set RTC alarm be active for a wakeup. But it's a little complex, isn't it? Cheers! MyungJoo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: Build instructions for directfb-1.6.0pre1-2011.11 ?
Hi, Compare to upstream, The only change is that you can enable NEON acceleration by --enable-neon config flag. In fact, the flag is auto by default. Ok, try following options on your platform. Compiler is gcc. DIRECTFB_CONF_OPT = \ --enable-static \ --enable-shared \ --enable-profiling\ --enable-debug \ --enable-debug-support \ --enable-neon \ --enable-voodoo \ --enable-trace \ --enable-text \ --program-prefix='' \ --enable-jpeg \ --enable-png \ --enable-gif \ --enable-linux-input \ --enable-zlib \ --enable-freetype \ --enable-linotype \ --enable-multicore \ --enable-fbdev \ --with-gfxdrivers=none \ --with-tests\ -Original Message- From: Dirk Behme [mailto:dirk.be...@de.bosch.com] Sent: Thursday, November 24, 2011 6:26 PM To: Kui Zheng Cc: linaro-dev@lists.linaro.org Subject: Build instructions for directfb-1.6.0pre1-2011.11 ? I just downloaded directfb-1.6.0pre1-2011.11.tar.bz2 from [1] and wonder what are the build options for this? I.e. what are the best/tested/recommended configure/compile options for this? And maybe which compiler to use (if this matters ;) )? Are there any binary packages available, too? Many thanks and best regards Dirk [1] https://launchpad.net/linaro-multimedia-project/2011.11/2011.11/ -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 3/4] omap-serial: Add minimal device tree support
On Monday 28 November 2011 07:09 PM, Rob Herring wrote:
On 11/22/2011 07:44 AM, Rajendra Nayak wrote:
Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks around OCP settings
to toggle forceidle/noidle/smaridle bits and handling
typo: smartidle
remote wakeup and dynamic muxing.
Signed-off-by: Rajendra Nayakrna...@ti.com
Acked-by: Rob Herringrob.herr...@calxeda.com
Thanks Rob, will fix the above typo.
Rob
---
.../devicetree/bindings/serial/omap_serial.txt | 10
drivers/tty/serial/omap-serial.c | 45 ++-
2 files changed, 52 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
new file mode 100644
index 000..342eedd
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -0,0 +1,10 @@
+OMAP UART controller
+
+Required properties:
+- compatible : should be ti,omap2-uart for OMAP2 controllers
+- compatible : should be ti,omap3-uart for OMAP3 controllers
+- compatible : should be ti,omap4-uart for OMAP4 controllers
+- ti,hwmods : Must be uartn, n being the instance number (1-based)
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f14b9c5..5aa524e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -38,6 +38,7 @@
#includelinux/serial_core.h
#includelinux/irq.h
#includelinux/pm_runtime.h
+#includelinux/of.h
#includeplat/dma.h
#includeplat/dmtimer.h
@@ -1324,6 +1325,19 @@ static void uart_tx_dma_callback(int lch, u16 ch_status,
void *data)
return;
}
+static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
+{
+ struct omap_uart_port_info *omap_up_info;
+
+ omap_up_info = devm_kzalloc(dev, sizeof(*omap_up_info), GFP_KERNEL);
+ if (!omap_up_info)
+ return NULL; /* out of memory */
+
+ of_property_read_u32(dev-of_node, clock-frequency,
+ omap_up_info-uartclk);
+ return omap_up_info;
+}
+
static int serial_omap_probe(struct platform_device *pdev)
{
struct uart_omap_port *up;
@@ -1331,6 +1345,9 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = pdev-dev.platform_data;
int ret = -ENOSPC;
+ if (pdev-dev.of_node)
+ omap_up_info = of_get_uart_port_info(pdev-dev);
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(pdev-dev, no mem resource?\n);
@@ -1375,9 +1392,20 @@ static int serial_omap_probe(struct platform_device
*pdev)
up-port.regshift = 2;
up-port.fifosize = 64;
up-port.ops =serial_omap_pops;
- up-port.line = pdev-id;
- sprintf(up-name, OMAP UART%d, up-port.line);
+ if (pdev-dev.of_node)
+ up-port.line = of_alias_get_id(pdev-dev.of_node, serial);
+ else
+ up-port.line = pdev-id;
+
+ if (up-port.line 0) {
+ dev_err(pdev-dev, failed to get alias/pdev id, errno %d\n,
+ up-port.line);
+ ret = -ENODEV;
+ goto err;
+ }
+
+ sprintf(up-name, OMAP UART%d, up-port.line);
up-port.mapbase = mem-start;
up-port.membase = ioremap(mem-start, resource_size(mem));
if (!up-port.membase) {
@@ -1530,7 +1558,7 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (!up)
return -EINVAL;
- if (!pdata-enable_wakeup)
+ if (!pdata || !pdata-enable_wakeup)
return 0;
if (pdata-get_context_loss_count)
@@ -1591,12 +1619,23 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops =
{
serial_omap_runtime_resume, NULL)
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_serial_of_match[] = {
+ { .compatible = ti,omap2-uart },
+ { .compatible = ti,omap3-uart },
+ { .compatible = ti,omap4-uart },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_serial_of_match);
+#endif
+
static struct platform_driver serial_omap_driver = {
.probe = serial_omap_probe,
.remove = serial_omap_remove,
.driver = {
.name = DRIVER_NAME,
.pm =serial_omap_dev_pm_ops,
+ .of_match_table = of_match_ptr(omap_serial_of_match),
},
};
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
