Re: Which kernel version fo 11.10?
On Wed, Oct 19, 2011 at 4:22 AM, Andy Green wrote: > We have working tilt-linux-linaro-3.0 and -3.1 for a little while now, > along with vanilla and android flavours and tracking, so we're set for > whatever people want. > > I think maybe Nicolas is surprised because Canonical Ubuntu stuff will stay > on 3.0, but I think it's better if Linaro Ubuntu packaged builds move on as > soon as possible and / or all have tracking-based hwpack option. > actually i was surprised for a different reason ;-) i thought we had issues with 3.1 kernel, and I didn't know they were fixed ! I am all for 3.1 asap. yes canonical/ubuntu will stay on 3.0, but i want to move to 3.1 asap (and 3.2 later on) in the TI or Linaro overlay. so i am good. > > Tracking-based build for Android has been a success and it reduces the > demand for wasteful backport effort to old releases if the fixed tracking > build is available too. > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [REMINDER] Jenkins and Ec2 plugin upgrade on Linaro CI [ ci.linaro.org]
Hello, Jenkins and Ec2 plugin upgrade on Linaro CI [ ci.linaro.org] is *complete*. ci.linaro.org has now jenkins updated to 1.419 and EC2 plugin to 1.13 version. ci.linaro.org service is operational now, please feel free to use it. On Tue, Oct 18, 2011 at 11:53 AM, Deepti Kalakeri < deepti.kalak...@linaro.org> wrote: > Hello, > > This is a reminder note to inform that jenkins and Ec2 plugin on > ci.linaro.org will be upgraded > tomorrow UTC *06:00:00 a.m. Wednesday October 19, 2011*. > > Complete details can be found below. > > Any concerns, please let me know. > > > -- Forwarded message -- > From: Deepti Kalakeri > Date: Fri, Oct 14, 2011 at 3:07 PM > Subject: Jenkins and Ec2 plugin upgrade on Linaro CI [ ci.linaro.org] > To: Alexander Sack , James Westby < > james.wes...@linaro.org>, linaro-dev > > > Hello, > > I'd like to upgrade Jenkins on ci.linaro.org to align with the > jenkins and ec2 plugin version on https://android-build.linaro.org/. > ci.linaro.org currently runs on jenkins version 1.400 and ec2 plugin > version 1.11, > the versions available on https://android-build.linaro.org/ for jenkins is > 1.419 > and for ec2 plugin is 1.13. > > I would like to upgrade jenkins to 1.419 and ec2 plugin to 1.13 on > ci.linaro.org > as these versions have been in production for quite a long time on andriod > build service > and has undergone rigorous usage without any problems/issues. > > I reviewed changelog and see that the upgrade would not cause any problems. > > So, I'd propose to perform upgrade Indian Standard Time 11 am, Wednesday > Oct 19th 2011. > Please let me know if there're any concerns. > > > -- > Thanks and Regards, > Deepti > Infrastructure Team Member, 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 > > > -- Thanks and Regards, Deepti Infrastructure Team Member, 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
linaro-media-create/linaro-android-media-create command line options changes
Hi, linaro-media-create/linaro-android-media-create command line options are now using dashes to separate words instead of underscores. e.g. "--image_size" becomes "--image-size" This changes is available on the bzr repository and will be part of 2011.10 release. Please, update your scripts and install instructions that are using the deprecated command line options. For reference: http://bugs.launchpad.net/bugs/863091 Cheers, -- Fathi Boudra Linaro Release Manager | Validation Project Manager 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: pinctrl_config APIs, and other pinmux questions
On Mon, Oct 17, 2011 at 08:51:11AM -0700, Stephen Warren wrote: > Shawn Guo wrote at Friday, October 14, 2011 9:12 PM: > > On Fri, Oct 14, 2011 at 08:53:33AM -0700, Stephen Warren wrote: > ... > > > Having the driver expose a list of all possible combinations of pin > > > configurations seems impractical, for the same reason as I objected to > > > the original proposal for how the driver listed functions; there are > > > simply far too many pin config parameters and legal value to list the > > > entire set of combinations. > > > > > I did not mean to list the entire set of combinations. For given > > function, the applicable number of config should be very limited. > > For most cases, it could be just one. For imx6q usdhc example, it's > > 3, for 50M, 100M and 200M SD bus clock cases. > > Shawn, > > Are you talking about entries in the (board-specific) mapping table, which > I agree would contain the useful subset of combinations of options, or a > list of possible settings exposed by the SoC driver, which would have to > expose all possibilities, or they wouldn't be available for the mapping > table to select from? > > In the case of "a list of possible settings exposed by the SoC driver", > > * If such a list (of combinations) were to exist, I think it'd need to > include all combinations (the cross-product of all individual config > params) in general. > > * I can certainly imagine that for some SoCs, or for a particular device > on a SoC, or for a particular board, only a subset of those would be useful, > and hence a limited set would be useful. However, that selection is up to > the board mapping table not the SoC driver in general. > > * In Tegra's case at least, I think a number of the numeric values (e.g. > pull strength with range 0..31) may be for board calibration, and besides > that, most combinations of param values would be useful in some case, and > hence we'd always have to expose everything, in order to allow the board > mapping table to be able to pick anything the designer needed. > > * As such, I think the SoC driver should at most list the legal range for > each param individually, and let the board-specific mapping table choose > the combination(s) required. > Yes, I meant the list of settings exposed by pinctrl driver. But it seems that in your case you need to list all the possible combinations of pin configurations. Then I agree it's impractical to have pinctrl driver to maintain this list. -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Which kernel version fo 11.10?
On 10/18/2011 12:23 PM, Somebody in the thread at some point said: On Mon, Oct 17, 2011 at 7:34 PM, Dechesne, Nicolas wrote: On Mon, Oct 17, 2011 at 6:07 PM, Nicolas Pitre wrote: Do we know yet which kernel version we are targeting for the Linaro 11.10 release? According to the latest weather forecast, this should be a 3.1 based kernel. really? is that true for Ubuntu LEB as well? Andy/Ricardo? In theory the LT kernels should all follow the Linux Linaro release, but for TILT I believe it depends on what Andy will have until the end of the cycle. We have working tilt-linux-linaro-3.0 and -3.1 for a little while now, along with vanilla and android flavours and tracking, so we're set for whatever people want. I think maybe Nicolas is surprised because Canonical Ubuntu stuff will stay on 3.0, but I think it's better if Linaro Ubuntu packaged builds move on as soon as possible and / or all have tracking-based hwpack option. Tracking-based build for Android has been a success and it reduces the demand for wasteful backport effort to old releases if the fixed tracking build is available too. -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
[REMINDER] Linaro 11.10 release dates and deliveries
Hi, This is a mail sent to remind you of the coming release dates: * Toolchain WG components for 11.10 were released on October 13, 2011. * Linaro 11.10 components release is October 20nd, 2011. * Linaro 11.10 RC images is October 24th, 2011. * Linaro 11.10 release is October 27th, 2011. The following components are planned to be delivered this month: * Graphics WG: compiz, compiz-plugins, glcompbench, glmark2, glproxy, nux, unity * Kernel WG: linux-linaro * Landing Teams: linux-linaro-lt-freescale, linux-linaro-android-lt-ti, linux-linaro-lt-samsung, linux-linaro-lt-st-ericsson, linux-linaro-lt-ti * Multimedia WG: libjpeg-turbo, test content, libpng * Platform Teams: u-boot-linaro, lava-android-test, lava-dashboard, lava-dashboard-tool, lava-dispatcher, lava-qatracker, lava-scheduler, lava-scheduler-tool, lava-server, lava-test, lava-tool, linaro-django-xmlrpc, linaro-image-tools, linaro-python-dashboard-bundle * Power Management WG: pm-qa, powerdebug, powertop * Toolchain WG: gcc-linaro 4.5, gcc-linaro 4.6, gdb-linaro, qemu-linaro The release dates and deliveries information is available from the release dashboard: http://wiki.linaro.org/Cycles/1110/Release/Dashboard -- David Zinman Linaro Release Manager | Project Manager 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: pinctrl_config APIs, and other pinmux questions
Linus Walleij wrote at Monday, October 17, 2011 9:03 AM:
> Thanks for a long letter, took som time to read, but as usual it
> contains good stuff!
>
> I think you're talking about two things here:
>
> 1) The need to configure per-pin "stuff" like biasing, driving,
> load capacitance ... whatever
>
> 2) The need to handle state transitions of pinmux settings.
Yes, that's true.
> I prefer that we try to keep these two separate and not conflate
> them too much.
>
> On Thu, Oct 13, 2011 at 10:59 PM, Stephen Warren wrote:
>
> > 2) Enhance the pin controller subsystem to support configuring these
> > properties.
>
> This is definately what we want to do. That is why the subsystem was
> renamed from pinmux to pinctrl in the first place, and also the rationale
> for introducing the abstract pin groups.
>
> > int (*pin_config)(unsigned pin, u32 param, u32 data);
> > int (*group_config)(unsigned group, u32 param, u32 data);
>
> Do you mean
> int (*group_config)(const char *group, u32 param, u32 data);
>
> On the latter one? We identify groups by name mainly.
> The selectors is an internal thing between pinctrl core and
> drivers.
That was a proposal for the core->driver API, so I think using an int
instead of a string makes sense?
> > Where "param" is some driver-specific parameter, such as:
> >
> > #define TEGRA_PINCTRL_PARAM_TRISTATE_ENABLE 0
> (...)
> > I looked at a bunch of existing pinmux drivers in the mainline kernel.
> > There are certainly some common concepts between SoCs. However, the
> > details are often different enough that I don't think attempting to
> > unify the set of configuration options will be that successful; I
> > doubt we could create a generic enough abstraction of these settings
> > for a cross-SoC driver to be able to usefully name and select values
> > for all the different pin/group options.
>
> I don't know, I could easily say the same thing about say input devices:
> all of them are essentially different, still they opted to create the file
> with this kind of stuff:
>
> ...
> #define KEY_COMMA 51
> #define KEY_DOT 52
> #define KEY_SLASH 53
> #define KEY_RIGHTSHIFT 54
> #define KEY_KPASTERISK 55
> ...
>
> And it has proven to be very useful. I'd rather opt to just remove
> the TEGRA_ prefix from all the above, and that we try to create some
> common sematics to these calls.
Hmm. Keys seem to have a bit more uniform behavior than the various
pin configuration data. Still, I guess I'm fine defining some unified
numbering space for all the parameters, so long as we can add Soc-specific
entries to the list when they don't match anything from other SoCs.
> > Data being a plain u32 rather than a pointer as your v7 patchset had it:
>
> Actually it looked like this:
>
> static inline int pinmux_config(struct pinmux *pmx, u16 param,
>unsigned long *data)
>
> That was supposed to be an unsigned long (not a *pointer), which
> is exchangeable to pointer, as per the example known from
> interrupt handlers. It can also be used to pass a plain argument.
> It was designed to be "ioctl()-like".
>
> So I prefer we say:
> int (*pin_config)(unsigned pin, u32 param, unsigned long data);
> int (*group_config)(const char *group, u32 param, unsigned long data);
For the data function parameter, that's the same as my proposal, except
for "unsigned long" rather than "u32".
...
> > Now let's suppose that we've enhanced the mapping table to support pin/
> > group_config values, and that a driver is written to expect a pinmux
> > mapping table with the following mappings:
> >
> > "active"
> > "suspend"
>
> I'm not following why this should be different mappings.
>
> I would rather contrast it with the similar concept from the
> regulator framework, these have modes like these:
>
> enum regulator_status {
> REGULATOR_STATUS_OFF,
> REGULATOR_STATUS_ON,
> REGULATOR_STATUS_ERROR,
> /* fast/normal/idle/standby are flavors of "on" */
> REGULATOR_STATUS_FAST,
> REGULATOR_STATUS_NORMAL,
> REGULATOR_STATUS_IDLE,
> REGULATOR_STATUS_STANDBY,
> };
>
> So I think we should have pin group states in a similar
> manner:
>
> enum pinmux_state {
> PINMUX_STATE_DEFAULT, /* == active */
> PINMUX_STATE_LOWPOWER,
> };
>
> And associated calls:
>
> pinmux_set_state(const char *group, enum pingroup_state state);
I don't think the pinctrl SoC driver could define what the param values
are for such a set of states; the set of parameters to vary, and the
values to set them to, is most likely board-specific.
Now, a board probably could define such a set of "states". Perhaps we'd
end up with the board supplying both a mapping table, and a "config
states" table. I suppose if the APIs to change pin config params between
states is separate from the API to acquire ownership of the pins and set
pin mux, as you proposed later in your email, then
[Patch 5/11] Regulator: DA9052/53 regulator support v5
The Dialog PMIC has below featured regulators:-
DA9052-BC - 4 DVS Buck converters 0.5V - 3.6V upto 1Amp.
DA9053-AA/BX - 4 DVS Buck converters 0.5V - 2.5V upto 3Amp.
DA9052/53 - 10 Programmable LDO's High PSSR, 1% accuracy.
This patch support all the DA9052 and Da9053 regulators. The output voltages are
fully programmable via I2C or SPI interface. The platform data with regulation
constraints is passed down from the board to the regulator.
Signed-off-by: David Dajun Chen
Signed-off-by: Ashish Jangam
Tested-by: Ying-Chun Liu (PaulLiu)
CC: Mark Brown
---
Changes since v5
- Modify Kconfig to describe the config symbol
- Change file permissions - remove execute permission
- Line 43 - Adjust for 80 characters width
Changes since v4
- Add support for DA9053
- Correct the definition of macros DA9052_BUCK_ILIM_MASK
- Get current limit to return current limit in microA
- Correct the voltage selector value for Buck Peri above 3v
- Set the struct member regualtor->da9052 in probe()
Changes since v3
- Corrected verify_range function
Changes since v2
- Check for current min_uA < 70
- Corrected current conversions from mA to uA
---
drivers/regulator/Kconfig|7 +
drivers/regulator/Makefile |1 +
drivers/regulator/da9052-regulator.c | 600 ++
3 files changed, 608 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/da9052-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 9713b1b..4f4774b 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -177,6 +177,13 @@ config REGULATOR_DA903X
Say y here to support the BUCKs and LDOs regulators found on
Dialog Semiconductor DA9030/DA9034 PMIC.
+config REGULATOR_DA9052
+ tristate "Dialog DA9052/DA9053 regulators"
+ depends on PMIC_DA9052
+ help
+ This driver supports the voltage regulators of DA9052-BC and
+ DA9053-AA/Bx PMIC.
+
config REGULATOR_PCF50633
tristate "PCF50633 regulator driver"
depends on MFD_PCF50633
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 93a6318..07b2126 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
+obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
diff --git a/drivers/regulator/da9052-regulator.c
b/drivers/regulator/da9052-regulator.c
new file mode 100644
index 000..9b75425
--- /dev/null
+++ b/drivers/regulator/da9052-regulator.c
@@ -0,0 +1,600 @@
+/*
+* da9052-regulator.c: Regulator driver for DA9052
+*
+* Copyright(c) 2011 Dialog Semiconductor Ltd.
+*
+* Author: David Dajun Chen
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License as published by
+* the Free Software Foundation; either version 2 of the License, or
+* (at your option) any later version.
+*
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* Buck step size */
+#define DA9052_BUCK_PERI_3uV_STEP 10
+#define DA9052_BUCK_PERI_REG_MAP_UPTO_3uV 24
+#define DA9052_CONST_3uV 300
+
+#define DA9052_MIN_UA 0
+#define DA9052_MAX_UA 3
+#define DA9052_CURRENT_RANGE 4
+
+/* Bit masks */
+#define DA9052_BUCK_ILIM_MASK_EVEN 0x0c
+#define DA9052_BUCK_ILIM_MASK_ODD 0xc0
+
+static const u32 da9052_current_limits[3][4] = {
+ {70, 80, 100, 120}, /* DA9052-BC BUCKs */
+ {160, 200, 240, 300}, /* DA9053-AA/Bx BUCK-CORE */
+ {80, 100, 120, 150},/* DA9053-AA/Bx BUCK-PRO,
+* BUCK-MEM and BUCK-PERI
+ */
+};
+
+struct da9052_regulator_info {
+ struct regulator_desc reg_desc;
+ int step_uV;
+ int min_uV;
+ int max_uV;
+ unsigned char volt_shift;
+ unsigned char en_bit;
+ unsigned char activate_bit;
+};
+
+struct da9052_regulator {
+ struct da9052 *da9052;
+ struct da9052_regulator_info *info;
+ struct regulator_dev *rdev;
+};
+
+static int verify_range(struct da9052_regulator_info *info,
+int min_uV, int max_uV)
+{
+ if (min_uV > info->max_uV || max_uV < info->min_uV)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int da9052_regulator_enable(struct regulator_dev *rdev)
+{
+ struct da9052_regulator *regulator = rdev_get_drvdata(rdev);
+ struct da9052_regulat
Re: [ACTIVITY] MMWG status - wk 41.2011 (20111010-20111014)
Some more changes now also added to the status link https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport 1. https://blueprints.launchpad.net/libjpeg-turbo/+spec/engr-mm-codec-jpeg-jcs-rgba888 will not make it to 1110 - work was larger than the time available 2. for libpng: a release will be made using version 1.5 of libpng. Ubuntu currently has version 1.2 but upstream has moved on to 1.5. Cost: we will need to carry both 1.2 and 1.5 version for a while as they are not compatible - but most apps will build cleanly against 1.5. 3. https://blueprints.launchpad.net/linaro-multimedia-x264/+spec/engr-multimedia-codec-x264-preload will not make it to 1110 - the community folks working on this one reported that the preload engine was working but the improvement was not obvious - so there will be no release related to x264 this month. Best regards, On 18/10/11 14:03, Ilias Biris wrote: > Status report with detail is in > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport > > Last weekly meeting minutes: > IRC logs linked in > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-10-11 > > == Highlights == > - Investigation ongoing for pulseaudio + UCM: thread is in > http://lists.linaro.org/pipermail/linaro-dev/2011-October/008160.html. > An analysis is also put in the wiki at > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs//AudioIntegration/UCMPulseAudio/Analyzation. > What is discussed in the list is the suggestion for improvements, ie > modelling of UCM concepts onto PulseAudio concepts. > > Seems that some of the discussion will be taken during > ELCE/LinuxCon/GstConf, next week, but unfortunately no MMWG members can > be there. The discussion during Connect is now being set up > > - For LJT: https://wiki.linaro.org/TomGall/LibJpegTurbo contains > benchmark data for > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-benchmark-libjpeg-turbo. > There seems to be a difference between LJT on Ubuntu and LJT on Android > in the order of about 25%. Investigation ongoing as to why > + Also on LJT: Working for 565 support. Code is generally there, > looking as to how to best generate / obtain test images slightly less > than obvious. Item seems risky for 1110 > > - For the UMM side of work: video codecs working, re-rebasing omapdrm > driver on latest linux-next and dss patches that are a dependency are > going in for 3.2 so Rob will try to get the omapdrm driver in as well. > Also work went on to get the camera board working on Panda this week. > > > - Other work: looking into the LAVA requirements for setting up > benchmarking tests for the codecs we have been working on > > - Ongoing discussion for the requirements for next cycle. > > 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: [ACTIVITY] MMWG status - wk 41.2011 (20111010-20111014)
On Tue, Oct 18, 2011 at 2:03 PM, Ilias Biris wrote: > - For LJT: https://wiki.linaro.org/TomGall/LibJpegTurbo contains > benchmark data for > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-benchmark-libjpeg-turbo. > There seems to be a difference between LJT on Ubuntu and LJT on Android > in the order of about 25%. Investigation ongoing as to why Any clues what could have caused that? The https://wiki.linaro.org/TomGall/LibJpegTurbo page says that "Linaro libjpeg-turbo 1.1.90 (current as of r702) + android extensions forward ported" was benchmarked. However the code from http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.git;a=shortlog;h=refs/heads/1.2-beta-linaro-andoid does not look like it was based on upstream libjpeg-turbo svn revision 702 (the ARM NEON code is not up to date). Is there any android libjpeg-turbo git tree or tarball other than the one announced in http://lists.linaro.org/pipermail/linaro-dev/2011-September/007219.html ? -- Best regards, Siarhei Siamashka ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [REMINDER] Jenkins and Ec2 plugin upgrade on Linaro CI [ ci.linaro.org]
On Tue, Oct 18, 2011 at 6:02 PM, Alexander Sack wrote: > Hi Deepti, > > > On Tue, Oct 18, 2011 at 8:23 AM, Deepti Kalakeri < > deepti.kalak...@linaro.org> wrote: > >> Hello, >> >> This is a reminder note to inform that jenkins and Ec2 plugin on >> ci.linaro.org will be upgraded >> tomorrow UTC *06:00:00 a.m. Wednesday October 19, 2011*. >> >> > Thanks for the reminder. Do you have an estimate on how long the > ci.linaro.org will be down? > Ah! this is my first attempt. If everything goes well, I believe it should not be down for more than an hour, but I can't promise. > > -- > 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 > > > -- Thanks and Regards, Deepti Infrastructure Team Member, 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: [REMINDER] Jenkins and Ec2 plugin upgrade on Linaro CI [ ci.linaro.org]
Hi Deepti, On Tue, Oct 18, 2011 at 8:23 AM, Deepti Kalakeri wrote: > Hello, > > This is a reminder note to inform that jenkins and Ec2 plugin on > ci.linaro.org will be upgraded > tomorrow UTC *06:00:00 a.m. Wednesday October 19, 2011*. > > Thanks for the reminder. Do you have an estimate on how long the ci.linaro.org will be down? -- 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
[ACTIVITY] GWG weekly status report - wk41.2011 (20111010-20111014)
Status report with details is in: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport Weekly meeting minutes are in: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-10-12 = Highlights = - Some items in the 1110 cycle were dropped. The work estimate was updated and the effort was greater than the time allowed for the release. These items are https://blueprints.launchpad.net/glproxy/+spec/glproxy-egl-virtualization https://blueprints.launchpad.net/glproxy/+spec/glproxy-support-glcompbench https://blueprints.launchpad.net/glmark2/+spec/glmark2-bump-mapping But at the same time a new item was added : Fader test scenario for glcompbench to simulate the fade in/out effect of many window managers glmark2: https://blueprints.launchpad.net/glcompbench/+spec/glcompbench-fade - glmark2 + Work on blueprints o https://blueprints.launchpad.net/glmark2/+spec/glmark2-mapbuffer-vs-bufferdata o Desktop window drop shadow benchmark in progress. (https://blueprints.launchpad.net/glmark2/+spec/glmark2-desktop-shadow) o Reviewed and merged extra models support. (https://blueprints.launchpad.net/glmark2/+spec/glmark2-extra-models) - UMM + Merging dma-mapping-v3 to Linaro kernel tree + dma-buf o posted v1 of RFC to upstream lists o started working on V4L2 camera on panda, to be able to use it for further work o started studying changes needed in V4L2 framework for dma-buf support, initially as a dma-buf user. - Perf events for GPU: Trying to find more complex benchmark for Origen board, also adding configuration for /proc/mali and updating it onto git.linaro.org - Unity/Nux/Compiz work ongoing - work is described in https://blueprints.launchpad.net/linaro-ubuntu/+spec/unity3d-working-with-oneiric - Other work: + Discussing best way to support linaro-media-create rootfs post-processing (https://bugs.launchpad.net/linaro-image-tools/+bug/751531). + In contact with apitrace developers to discuss EGL/GLES2.0 support - New member - part time working for Linaro: Marcus Lorentzon joins us from ST-Ericsson, will focus on the buffer sharing enablement effort for ST-E platforms -- 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: [ACTIVITY] MMWG status - wk 41.2011 (20111010-20111014)
forgot to mention that for Connect hacking and team sessions, the GFX and MMWG teams are now collecting the plans under https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Events/LCQ4.11-Orlando The two teams will be collocated in Curacao4 room. BR, Ilias On 18/10/11 14:03, Ilias Biris wrote: > Status report with detail is in > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport > > Last weekly meeting minutes: > IRC logs linked in > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-10-11 > > == Highlights == > - Investigation ongoing for pulseaudio + UCM: thread is in > http://lists.linaro.org/pipermail/linaro-dev/2011-October/008160.html. > An analysis is also put in the wiki at > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs//AudioIntegration/UCMPulseAudio/Analyzation. > What is discussed in the list is the suggestion for improvements, ie > modelling of UCM concepts onto PulseAudio concepts. > > Seems that some of the discussion will be taken during > ELCE/LinuxCon/GstConf, next week, but unfortunately no MMWG members can > be there. The discussion during Connect is now being set up > > - For LJT: https://wiki.linaro.org/TomGall/LibJpegTurbo contains > benchmark data for > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-benchmark-libjpeg-turbo. > There seems to be a difference between LJT on Ubuntu and LJT on Android > in the order of about 25%. Investigation ongoing as to why > + Also on LJT: Working for 565 support. Code is generally there, > looking as to how to best generate / obtain test images slightly less > than obvious. Item seems risky for 1110 > > - For the UMM side of work: video codecs working, re-rebasing omapdrm > driver on latest linux-next and dss patches that are a dependency are > going in for 3.2 so Rob will try to get the omapdrm driver in as well. > Also work went on to get the camera board working on Panda this week. > > > - Other work: looking into the LAVA requirements for setting up > benchmarking tests for the codecs we have been working on > > - Ongoing discussion for the requirements for next cycle. > > 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
[ACTIVITY] MMWG status - wk 41.2011 (20111010-20111014)
Status report with detail is in https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Last weekly meeting minutes: IRC logs linked in https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-10-11 == Highlights == - Investigation ongoing for pulseaudio + UCM: thread is in http://lists.linaro.org/pipermail/linaro-dev/2011-October/008160.html. An analysis is also put in the wiki at https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs//AudioIntegration/UCMPulseAudio/Analyzation. What is discussed in the list is the suggestion for improvements, ie modelling of UCM concepts onto PulseAudio concepts. Seems that some of the discussion will be taken during ELCE/LinuxCon/GstConf, next week, but unfortunately no MMWG members can be there. The discussion during Connect is now being set up - For LJT: https://wiki.linaro.org/TomGall/LibJpegTurbo contains benchmark data for https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-benchmark-libjpeg-turbo. There seems to be a difference between LJT on Ubuntu and LJT on Android in the order of about 25%. Investigation ongoing as to why + Also on LJT: Working for 565 support. Code is generally there, looking as to how to best generate / obtain test images slightly less than obvious. Item seems risky for 1110 - For the UMM side of work: video codecs working, re-rebasing omapdrm driver on latest linux-next and dss patches that are a dependency are going in for 3.2 so Rob will try to get the omapdrm driver in as well. Also work went on to get the camera board working on Panda this week. - Other work: looking into the LAVA requirements for setting up benchmarking tests for the codecs we have been working on - Ongoing discussion for the requirements for next cycle. 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
