On Thu, Oct 7, 2010 at 11:45 PM, Alex Gonzalez wrote:
> Hi,
> I haven't found any list for generic embedded linux questions so please
> redirect
> me if you know one.
> I am working on a Freescale MX51 board with a MC13892 PMIC which has a
> battery driver to
> monitor and control the battery. If
On Thu, 7 Oct 2010, Mathieu Poirier wrote:
> This set of patches add dynamic ftrace capabilities to ARM. As
> requested, it is now based on the linux-linaro-2.6.35 stable tree.
Pulled and pushed, thanks.
Nicolas
___
linaro-dev mailing list
linaro-de
This set of patches add dynamic ftrace capabilities to ARM. As
requested, it is now based on the linux-linaro-2.6.35 stable tree.
This work has been submitted here:
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=shortlog;h=80be7a7f642719bf99fc49692fc77d6333f51a73
BugLink: https:/
On Thu, 7 Oct 2010, Sudip Jain wrote:
> Hi,
>
> Please find attached patches for enabling 'X' using xorg-fbdev and xorg-ste
> driver on MOP500 hrefp boards.
This patch would never be accepted in mainline.
Why do you have to modify generic code that way? Couldn't you deal with
such quirks insi
On Thu, 7 Oct 2010, Vishwanath Sripathy wrote:
> Hi All,
>
> Purpose of this email is to debate on the pros and cons of having a common
> ARM context save/restore code.
> Currently each SOC has its own way of saving/restoring ARM registers and
> there has been a proposal to have a common code for
Hi,
I haven't found any list for generic embedded linux questions so please
redirect
me if you know one.
I am working on a Freescale MX51 board with a MC13892 PMIC which has a
battery driver to
monitor and control the battery. If I were to develop a battery powered
device based on
it, I would nee
Hi,
notes and actions from our Tuesday multimedia cross-vendor call are
available on the wiki:
+ https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2010-10-05
Details about when and where of this meeting can be found here:
+
https://wiki.linaro.org/WorkingGroups/Middleware/Mul
Hi,
notes and actions from our Monday graphics cross-vendor call are
available on the wiki:
+ https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2010-10-04
Details about when and where of this meeting can be found here:
+
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics
Mathieu,
This should probably go in via the linux-linaro-2.6.35 stable tree:
git://git.linaro.org/kernel/linux-linaro-2.6.35.git
Looks like your tree is a clone of the linux-linaro packaging tree
git://git.linaro.org/ubuntu/linux-linaro.git which is a merge of the
stable tree above plus ubuntu pl
Hi,
On Thu, Oct 7, 2010 at 3:13 PM, Wookey wrote:
[...]
> And whilst on the subject - do the other libs like gomp mudflap and
> erm that come of of toolchain builds need to be built in
> the same set of flavours or is this issue restricted to libgcc?
I think that libgcc is the only thing you ca
This set of patches add dynamic ftrace capabilities to ARM.
This work has been submitted here:
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=shortlog;h=80be7a7f642719bf99fc49692fc77d6333f51a73
The following changes since commit d0bbdab2bb2c55c3dc6a4b3fd2128250dff99feb:
John Rig
Sudip,
I applied these yesterday with Frederick's help. The changes are here:
git://git.linaro.org/bsp/st-ericsson/linux-2.6.34-ux500.git
The kernel source change is in the master branch. The kernel config
change is in the packaging branch.
The resulting kernel binary package is available in
+++ Andrew Stubbs [2010-10-07 12:46 +0100]:
> On 07/10/10 12:03, Wookey wrote:
> A possible solution to the problem would be to include the sources to
> libgcc.a in the installation, and teach gcc to compile it on-the-fly, as
> necessary.
If it was possible to separate-out libgcc somewhat so
On Wed, Oct 6, 2010 at 11:13 AM, Shawn Guo wrote:
> On Thu, Sep 30, 2010 at 5:37 PM, Loïc Minier wrote:
>>> >> + cat > ${TMP_DIR}/boot.cmd << BOOTCMD
>>> >> +setenv bootcmd 'fatload mmc 0:1 0x9000 uImage; fatload mmc 0:1
>>> >> 0x9080 uInitrd; bootm 0x9000 0x9080'
>>> >
>>> >
> > Using wp_tbl is because that it also contains information like regulator
> > voltage.
>
> The clock code does not handle the regulators, not even in the fsl
> kernel.
>
I did not mean to say clock code will handle regulators. I mean this table
also contains such information which may be needed
On Thursday 07 October 2010 13:03:14 Wookey wrote:
> gcc has the multilib feature, but the way it is implemented means it
> works well for about 2 or 3 options, but you rapidly get combinatorial
> explosion of libgcc instances if you try to do more things than that.
> (i.e if you ask for v5, v6, v7
On 07/10/10 12:03, Wookey wrote:
gcc has the multilib feature, but the way it is implemented means it
works well for about 2 or 3 options, but you rapidly get combinatorial
explosion of libgcc instances if you try to do more things than that.
(i.e if you ask for v5, v6, v7, vfp, and neon options
On Thu, Oct 7, 2010 at 2:33 PM, Yong Shen wrote:
>
>> > # Object file lists.
>> > -obj-y := cpu.o mm.o clock-mx51.o devices.o
>> > +obj-y := cpu.o mm.o clock-mx51.o devices.o cpu_wp-mx51.o
>>
>> By hardcoding cpu_wp-mx51 here, you are making the assumption that even if
>> cpufreq is turned of
> > # Object file lists.
> > -obj-y := cpu.o mm.o clock-mx51.o devices.o
> > +obj-y := cpu.o mm.o clock-mx51.o devices.o cpu_wp-mx51.o
>
> By hardcoding cpu_wp-mx51 here, you are making the assumption that even if
> cpufreq is turned off, you'll still need the entire WP table to set the
> cpu
+++ John Rigby [2010-10-06 08:31 -0600]:
> I'm really sorry to have started this, but for completeness here is
> the rest of the story. The hypothetical scenario is a developer that
> maintains u-boot for multiple platforms. Using a codesourcery or eldk
> (from denx.de) toolchain one can use the
Hi,
Its that time again, today is Linaro image testing day. If you have
supported hardware and are willing to test the images, please make your
way to:
http://wiki.linaro.org/Releases/DailyBuilds
for an explanation on how to test and submit your results to the QA
tracker at:
http://qat
On Thu, Oct 07, 2010 at 10:40:44AM +0300, Amit Kucheria wrote:
> On 10 Oct 07, Yong Shen wrote:
> >
> > > > +static struct cpufreq_frequency_table imx_freq_table[4];
> > >
> > > Three frequencies should be enough for everyone, right? This should be
> > > dynamically allocated like in other cpufreq
On Thu, Oct 07, 2010 at 11:36:07AM +0800, Yong Shen wrote:
> Hi Sascha,
>
> Thanks for your thorough comments.
> I have already received comments from Arnd before yours arrived. So some of
> the commends you two provided are common.
> I acknowledge most of your opinions, except for two, I have som
Some comments inline.
On 10 Oct 07, Yong Shen wrote:
> From: Yong Shen
>
> it is tested on babbage 3.0
>
> Signed-off-by: Yong Shen
> ---
> arch/arm/Kconfig |6 +
> arch/arm/mach-mx5/Kconfig |1 +
> arch/arm/mach-mx5/Makefile |2 +-
>
On 10 Oct 07, Yong Shen wrote:
>
> > > +static struct cpufreq_frequency_table imx_freq_table[4];
> >
> > Three frequencies should be enough for everyone, right? This should be
> > dynamically allocated like in other cpufreq drivers.
> >
>
> Yes, we only support 3 work points, which is for sure. A
25 matches
Mail list logo
