Re: [yocto] [PATCH 1/1] RTC: Ensure msecure is mux'd to be able to set RTC
Op 16 jun 2011, om 08:07 heeft Jingdong Lu het volgende geschreven:
> From: Jingdong Lu
>
> commit e2a346a2a054f702fd76f328ff747b9ad9264a4c from
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
When I do 'git show e2a346a2a054f702fd76f328ff747b9ad9264a4' I get:
commit e2a346a2a054f702fd76f328ff747b9ad9264a4c
Author: Alexander Holler
^
Date: Tue Apr 5 15:40:08 2011 +0200
arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC
Without msecure beeing high it isn't possible to set (or start)
the RTC.
Tested with a BeagleBoard C4.
Signed-off-by: Alexander Holler
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index be71426..d64ed97 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -579,6 +579,9 @@ static void __init omap3_beagle_init(void)
omap_nand_flash_init(NAND_BUSWIDTH_16, omap3beagle_nand_partitions,
ARRAY_SIZE(omap3beagle_nand_partitions));
+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
So if you're going to change the author, you'd also need to remove the SOBs.
>
> arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC.
> "Msecure" signal provides for protection of the RTC register in TPS65950 be
> disabling that function via a control signal from the OMAP3530. So ensure
> msecure is mux'd to be able to set the RTC.
>
> Tested with a BeagleBoard C4.
> Fixes bug [YOCTO #767]
>
> Signed-off-by: Alexander Holler
> Signed-off-by: Tony Lindgren
> Integrated-by: Jingdong Lu
> ---
> arch/arm/mach-omap2/board-omap3beagle.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index af1166b..925c0b3 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
> usb_ehci_init(&ehci_pdata);
> omap3beagle_flash_init();
>
> + /* Ensure msecure is mux'd to be able to set the RTC. */
> + omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
> +
> /* Ensure SDRC pins are mux'd for self-refresh */
> omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
> omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
> --
> 1.7.0.4
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] RTC: Ensure msecure is mux'd to be able to set RTC
On 06/16/11 02:13, Liming Wang wrote:
On 2011-6-16 14:07, Jingdong Lu wrote:
From: Jingdong Lu
commit e2a346a2a054f702fd76f328ff747b9ad9264a4c from
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
It's fine if you break this line into two lines.
arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC.
"Msecure" signal provides for protection of the RTC register in
TPS65950 be
disabling that function via a control signal from the OMAP3530. So ensure
msecure is mux'd to be able to set the RTC.
Tested with a BeagleBoard C4.
Fixes bug [YOCTO #767]
I think it's best to put your comment in the top line.
And we don't want the bug tracking information directly
in the kernel commits, it just ends up cluttering things.
It's fine to include this in the 0/N email, but not in
the commit message itself.
Cheers,
Bruce
Liming Wang
Signed-off-by: Alexander Holler
Signed-off-by: Tony Lindgren
Integrated-by: Jingdong Lu
---
arch/arm/mach-omap2/board-omap3beagle.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..925c0b3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();
+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] RTC: Ensure msecure is mux'd to be able to set RTC
On 06/16/11 03:27, Koen Kooi wrote:
Op 16 jun 2011, om 08:07 heeft Jingdong Lu het volgende geschreven:
From: Jingdong Lu
commit e2a346a2a054f702fd76f328ff747b9ad9264a4c from
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
When I do 'git show e2a346a2a054f702fd76f328ff747b9ad9264a4' I get:
commit e2a346a2a054f702fd76f328ff747b9ad9264a4c
Author: Alexander Holler
^
Date: Tue Apr 5 15:40:08 2011 +0200
arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC
Without msecure beeing high it isn't possible to set (or start)
the RTC.
Tested with a BeagleBoard C4.
Signed-off-by: Alexander Holler
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index be71426..d64ed97 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -579,6 +579,9 @@ static void __init omap3_beagle_init(void)
omap_nand_flash_init(NAND_BUSWIDTH_16, omap3beagle_nand_partitions,
ARRAY_SIZE(omap3beagle_nand_partitions));
+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
So if you're going to change the author, you'd also need to remove the SOBs.
It's likely just a glitch in patch generation.
Jindong: did you cherry-pick or git am this for the import
into your tree ? Or did you use another technique ?
If done properly, the author is always maintained in our
imported patches.
Cheers,
Bruce
arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC.
"Msecure" signal provides for protection of the RTC register in TPS65950 be
disabling that function via a control signal from the OMAP3530. So ensure
msecure is mux'd to be able to set the RTC.
Tested with a BeagleBoard C4.
Fixes bug [YOCTO #767]
Signed-off-by: Alexander Holler
Signed-off-by: Tony Lindgren
Integrated-by: Jingdong Lu
---
arch/arm/mach-omap2/board-omap3beagle.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..925c0b3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();
+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] Enable to set RTC for beagleboard
On 06/15/2011 09:25 PM, Bruce Ashfield wrote: > On 11-06-15 10:23 PM, Lu Jingdong wrote: >> On 06/16/2011 01:33 AM, Darren Hart wrote: >>> >>> On 06/15/2011 09:52 AM, Bruce Ashfield wrote: On 06/15/11 12:48, Darren Hart wrote: > > On 06/15/2011 06:31 AM, Bruce Ashfield wrote: >> On 06/15/11 09:25, Koen Kooi wrote: >>> Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende >>> geschreven: >>> On 06/15/11 06:41, Jingdong Lu wrote: > From: Jingdong Lu > > Ensure msecure is mux'd to be able to set the RTC for > beagleboard. Fixes bug [YOCTO #767] Jingdong, The fix looks reasonable to me, Darren has been refreshing the beagleboard support as well, so I've cc'd him here to see if we have this change present in the work in progress trees. > > I do not have something similar queued. > > What tests did you run to ensure that the RTC worked on the beagleboard ? There was some debate around whether or not you needed an add-on card to get this functionality available ? >> The signal "msecure" on TPS65950 connects to "msecure" on OMAP3530 and >> setting/writing RTC register is controlled by >> OMAP3530 "msecure". So we should pull the "msecure" high on OMAP3530 so >> that we can set/write RTC register on TPS65950. >> >> We test RTC on beagleboard by adding this patch. RTC can be set a >> correct date and >> it works well when power on. >>> You need to remove some resistors and add a battery, or add an >>> expansionboard like the zippy or zippy2, which have a DS1307 RTC >>> with battery. >> Because there is no backup battery on beagleboard C4, RTC can not be >> saved when >> power off. If we want to keep RTC without power, we should remove R66 >> and install >> a battery on board. > > Ack'd. For me, this is reasonable. Having a working RTC even > if it doesn't survive power cycle is worth having. In particular, > since the patch is simple. Agreed. > >> >> Thanks Koen, >> >> This confirms what I thought (zippy*), so clearly this is either a >> board with that setup, or runtime testing was .. unique. Either way, >> more details and research is needed for this one. > > I'll wait to hear upstream status on this. Given the requirements for > use, I wouldn't mind just closing 767 as will not fix as it can't work > with the beagleboard out of the box anyway. I'm ok with that resolution .. for the bug. But if the patch isn't already in another upstream tree, it's worth having (if benign to the rest of the variants) and then we can get it sent upstream from there. I can change the bug's status if you like. >>> >>> I want to hear back from Jingdong regarding this patch first. Is this >>> new code? If so, then yes, let's get it to mainline as Bruce suggested. >>> >> >> This patch can be found on linux-omap tree. >> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=e2a346a2a054f702fd76f328ff747b9ad9264a4c >> > > perfect. > >> >> arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC >> Without msecure beeing high it isn't possible to set (or start) >> the RTC. >> >> Tested with a BeagleBoard C4. >> >> Signed-off-by: Alexander Holler >> Signed-off-by: Tony Lindgren >> >> So maybe I should recommit it by adding some upstream status and author. > > This is key. We must have this in our patch commits. I can provide > examples if you aren't familiar and Mark Hatle just sent out some oe-core > examples of the same thing. > > In this case you'd put something like: > > commit e2a346a2a054f7 from > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git > > after the shortlog, and before the long log. Add your Integrated-by: > to the sign off section of the patch. > I will just pull the patch and add Jingdong as the Integrated-by. -- Darren > Cheers, > > Bruce > > >> >> regards, >> >> Jingdong Cheers, Bruce > > -- > Darren > >> Cheers, >> >> Bruce >> >>> regards, >>> >>> Koen >> ___ yocto mailing list >> yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto >> > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] Enable to set RTC for beagleboard
Op 16 jun 2011, om 16:45 heeft Darren Hart het volgende geschreven: > > On 06/15/2011 09:25 PM, Bruce Ashfield wrote: >> On 11-06-15 10:23 PM, Lu Jingdong wrote: >>> On 06/16/2011 01:33 AM, Darren Hart wrote: On 06/15/2011 09:52 AM, Bruce Ashfield wrote: > On 06/15/11 12:48, Darren Hart wrote: >> >> On 06/15/2011 06:31 AM, Bruce Ashfield wrote: >>> On 06/15/11 09:25, Koen Kooi wrote: Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende geschreven: > On 06/15/11 06:41, Jingdong Lu wrote: >> From: Jingdong Lu >> >> Ensure msecure is mux'd to be able to set the RTC for >> beagleboard. Fixes bug [YOCTO #767] > Jingdong, > > The fix looks reasonable to me, Darren has been refreshing the > beagleboard support as well, so I've cc'd him here to see if we > have this change present in the work in progress trees. > >> >> I do not have something similar queued. >> >> > What tests did you run to ensure that the RTC worked on the > beagleboard ? There was some debate around whether or not you > needed an add-on card to get this functionality available ? >>> The signal "msecure" on TPS65950 connects to "msecure" on OMAP3530 and >>> setting/writing RTC register is controlled by >>> OMAP3530 "msecure". So we should pull the "msecure" high on OMAP3530 so >>> that we can set/write RTC register on TPS65950. >>> >>> We test RTC on beagleboard by adding this patch. RTC can be set a >>> correct date and >>> it works well when power on. You need to remove some resistors and add a battery, or add an expansionboard like the zippy or zippy2, which have a DS1307 RTC with battery. >>> Because there is no backup battery on beagleboard C4, RTC can not be >>> saved when >>> power off. If we want to keep RTC without power, we should remove R66 >>> and install >>> a battery on board. >> >> Ack'd. For me, this is reasonable. Having a working RTC even >> if it doesn't survive power cycle is worth having. In particular, >> since the patch is simple. > > > Agreed. FWIW, it survives warm resests. regards, Koen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] configure optimization feature update
Hi Dongxiao,
On Thu, 2011-06-16 at 08:57 +0800, Xu, Dongxiao wrote:
> Recently I was doing the "configure optimization" feature and
> collecting data for it.
>
> The main logic of this feature is straight forward:
>
> 1. Use the diff file as autoreconf cache. (I use command: "diff -ruN
> SOURCE-ORIG SOURCE", here "SOURCE-ORIG" is the source directory before
> running autoreconf, while "SOURCE" is the directory after running
> autoreconf).
> 2. Add SRC_URI checksum for all patches of the source code.
> 3. Tag each autoreconf cache file with ${PN} and the SRC_URI checksum
> of source code and all patches.
> 4. If the currently SRC_URI checksum matches the cached checksum, then
> we can patch the cache instead of running "autoreconf" stage.
>
> I did some testings for sato build, the result is not as good as we
> expected:
>
> On a server build machine (Genuine Intel(R) CPU @ 2.40GHz, 2 sockets with 6
> core each and hyperthreading, thus 24 logical CPUs in all, 66G memory):
>
> w/o the optimization:
> real83m40.963s
> user496m58.550s
> sys 329m1.590s
>
> w/ the optimization:
> real79m1.062s
> user460m58.600s
> sys 347m42.120s
>
> It has about 5% performance gain.
Whats interesting there is the relatively large sys times compared to
user. Any idea why that's happening? Spinning locks?
> I also tested the patch on a desktop core-i7 machine (Intel(R) Core(TM) i7
> CPU 870 @ 2.93GHz, 4 core 8 logical CPU, 4G memory):
>
> w/o the optimization:
> real105m25.436s
> user372m48.040s
> sys 51m23.950s
>
> w/ the optimization:
> real103m38.314s
> user332m35.770s
> sys 49m4.520s
>
> It only has about 2% performance gain.
>
> The result is not encouraging.
Agreed, this isn't as good as we'd hoped for :(.
> There are also some other things we need to take into consideration
> for this feature:
>
> 1. If add this feature, the first build time should be longer than
> current since it needs to build the autoreconf cache.
> 2. Maintainers needs to maintain the SRC_URI checksums not only for
> source code, but also all its patches. For some recipes, it has more
> than 20 patches, which needs assignable maintenance effort.
> 3. How to distribute the caches will be a problem. The total size of
> such cache is about 900M (before compression) and 200M (after
> compression). Since the size is not small, distributing it with Poky
> source code doesn't make sense. On another aspect, we can use
> something like "sstate". But since we already have caches of sstate, I
> think it is not necessary for us to enable another similar cache
> mechanism with little improvement.
>
> Therefore my opinion is we may give up this feature. What's your
> comments and suggestions?
I think we should put the patches together on a branch in contrib so we
keep them somewhere in case we want them. Certainly tracking what
changes the autoreconf process makes may be useful in other situations
in future so its worth keeping the patches. I think you're right and we
should shelve the idea for now though as it doesn't look to be worth the
pain it entails.
For reference, we probably do need to start tracking the file checksums
for the benefit of sstate.
The mediocre performance improvement is likely down to the size of the
cache data but I can't immediately think of a way to improve that :(.
Cheers,
Richard
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [KERNEL][PATCH] add utrace
On 06/13/11 10:35, tom.zanu...@intel.com wrote: From: Tom Zanussi This adds support for utrace to linux-yocto, for userspace tracing in systemtap. Please pull into the yocto/base branch linux-yocto. Pull URL: git://git.pokylinux.org/linux-yocto-2.6.37-contrib Branch: tzanussi/yocto/base-utrace Browse: http://git.pokylinux.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/yocto/base-utrace These are merged, and pushed. I put this in a common location so all BSPs have the changes. I'm doing some final build testing now, but I'll have a SRCREV update for this later today. Cheers, Bruce Tom Zanussi (1): utrace: support for user space probing/tracing Documentation/DocBook/Makefile|2 +- Documentation/DocBook/utrace.tmpl | 589 + fs/proc/array.c |3 + include/linux/ptrace.h|1 + include/linux/sched.h |6 + include/linux/tracehook.h | 97 ++- include/linux/utrace.h| 692 +++ init/Kconfig |9 + kernel/Makefile |1 + kernel/fork.c |3 + kernel/ptrace.c | 16 +- kernel/signal.c |4 +- kernel/utrace.c | 2440 + 13 files changed, 3853 insertions(+), 10 deletions(-) create mode 100644 Documentation/DocBook/utrace.tmpl create mode 100644 include/linux/utrace.h create mode 100644 kernel/utrace.c ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] configure optimization feature update
Hi Richard,
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Thursday, June 16, 2011 11:01 PM
> To: Xu, Dongxiao
> Cc: yocto@yoctoproject.org
> Subject: Re: configure optimization feature update
>
> Hi Dongxiao,
>
> On Thu, 2011-06-16 at 08:57 +0800, Xu, Dongxiao wrote:
> > Recently I was doing the "configure optimization" feature and
> > collecting data for it.
> >
> > The main logic of this feature is straight forward:
> >
> > 1. Use the diff file as autoreconf cache. (I use command: "diff -ruN
> > SOURCE-ORIG SOURCE", here "SOURCE-ORIG" is the source directory before
> > running autoreconf, while "SOURCE" is the directory after running
> > autoreconf).
> > 2. Add SRC_URI checksum for all patches of the source code.
> > 3. Tag each autoreconf cache file with ${PN} and the SRC_URI checksum
> > of source code and all patches.
> > 4. If the currently SRC_URI checksum matches the cached checksum, then
> > we can patch the cache instead of running "autoreconf" stage.
> >
> > I did some testings for sato build, the result is not as good as we
> > expected:
> >
> > On a server build machine (Genuine Intel(R) CPU @ 2.40GHz, 2 sockets with 6
> core each and hyperthreading, thus 24 logical CPUs in all, 66G memory):
> >
> > w/o the optimization:
> > real83m40.963s
> > user496m58.550s
> > sys 329m1.590s
> >
> > w/ the optimization:
> > real79m1.062s
> > user460m58.600s
> > sys 347m42.120s
> >
> > It has about 5% performance gain.
>
> Whats interesting there is the relatively large sys times compared to user.
> Any
> idea why that's happening? Spinning locks?
Yes, I also noticed the the in-consistent data of user and sys.
During the build, sometimes I found the build will suspend for some time and
system is doing "kjournald".
It happens relatively frequent on that 24 CPU's server with "48" and "-j48"
assigned for build parallel parameters.
I am not sure whether this caused the above phenomenon.
>
> > I also tested the patch on a desktop core-i7 machine (Intel(R) Core(TM) i7
> CPU 870 @ 2.93GHz, 4 core 8 logical CPU, 4G memory):
> >
> > w/o the optimization:
> > real105m25.436s
> > user372m48.040s
> > sys 51m23.950s
> >
> > w/ the optimization:
> > real103m38.314s
> > user332m35.770s
> > sys 49m4.520s
> >
> > It only has about 2% performance gain.
> >
> > The result is not encouraging.
>
> Agreed, this isn't as good as we'd hoped for :(.
>
> > There are also some other things we need to take into consideration
> > for this feature:
> >
> > 1. If add this feature, the first build time should be longer than
> > current since it needs to build the autoreconf cache.
> > 2. Maintainers needs to maintain the SRC_URI checksums not only for
> > source code, but also all its patches. For some recipes, it has more
> > than 20 patches, which needs assignable maintenance effort.
> > 3. How to distribute the caches will be a problem. The total size of
> > such cache is about 900M (before compression) and 200M (after
> > compression). Since the size is not small, distributing it with Poky
> > source code doesn't make sense. On another aspect, we can use
> > something like "sstate". But since we already have caches of sstate, I
> > think it is not necessary for us to enable another similar cache
> > mechanism with little improvement.
> >
> > Therefore my opinion is we may give up this feature. What's your
> > comments and suggestions?
>
> I think we should put the patches together on a branch in contrib so we keep
> them somewhere in case we want them. Certainly tracking what changes the
> autoreconf process makes may be useful in other situations in future so its
> worth keeping the patches. I think you're right and we should shelve the idea
> for now though as it doesn't look to be worth the pain it entails.
OK, I will queue my patch into a contrib tree and keep it there.
>
> For reference, we probably do need to start tracking the file checksums for
> the
> benefit of sstate.
Could you explain more here? Here the file checksums you mentioned is SRC_URI
checksum?
How can it help sstate?
Thanks,
Dongxiao
>
> The mediocre performance improvement is likely down to the size of the cache
> data but I can't immediately think of a way to improve that :(.
>
> Cheers,
>
> Richard
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] RTC: Ensure msecure is mux'd to be able to set RTC
On 2011-6-16 21:20, Bruce Ashfield wrote:
On 06/16/11 02:13, Liming Wang wrote:
On 2011-6-16 14:07, Jingdong Lu wrote:
From: Jingdong Lu
commit e2a346a2a054f702fd76f328ff747b9ad9264a4c from
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
It's fine if you break this line into two lines.
arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC.
"Msecure" signal provides for protection of the RTC register in
TPS65950 be
disabling that function via a control signal from the OMAP3530. So
ensure
msecure is mux'd to be able to set the RTC.
Tested with a BeagleBoard C4.
Fixes bug [YOCTO #767]
I think it's best to put your comment in the top line.
And we don't want the bug tracking information directly
in the kernel commits, it just ends up cluttering things.
It's fine to include this in the 0/N email, but not in
the commit message itself.
Yes, I agree.
Jingdong should generate a new patch by cherry-pick or format-patch.
Liming Wang
Cheers,
Bruce
Liming Wang
Signed-off-by: Alexander Holler
Signed-off-by: Tony Lindgren
Integrated-by: Jingdong Lu
---
arch/arm/mach-omap2/board-omap3beagle.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..925c0b3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();
+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC
From: Jingdong Lu arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC Fixes bug [YOCTO #767] Alexander Holler (1): arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC arch/arm/mach-omap2/board-omap3beagle.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC
From: Alexander Holler
commit e2a346a2a054f702fd76f328ff747b9ad9264a4c from
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
Without msecure beeing high it isn't possible to set (or start)
the RTC.
Tested with a BeagleBoard C4.
Signed-off-by: Alexander Holler
Signed-off-by: Tony Lindgren
Integrated-by: Jingdong Lu
---
arch/arm/mach-omap2/board-omap3beagle.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..925c0b3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();
+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
--
1.7.0.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] linux-yocto/meta-yocto: bump SRCREVs for utrace
Richard/Saul, Updating the SRCREVs to take into acccount the utrace update from Tom. With this, the stage is set for systemtap support. The following changes since commit 2163461ec94528ecf046a04edc5db3d2dd3a6b8b: Tom Zanussi (1): systemtap: remove non-core COMPATIBLE_MACHINES are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (1): linux-yocto/meta-yocto: update SRCREVs for utrace merge .../linux/linux-yocto_2.6.37.bbappend | 10 +- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] linux-yocto/meta-yocto: update SRCREVs for utrace merge
Updating the SRCREVs to account for the merge of utrace to support systemtap. Signed-off-by: Bruce Ashfield --- .../linux/linux-yocto_2.6.37.bbappend | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto_2.6.37.bbappend b/meta-yocto/recipes-kernel/linux/linux-yocto_2.6.37.bbappend index 84e31e9..502ae76 100644 --- a/meta-yocto/recipes-kernel/linux/linux-yocto_2.6.37.bbappend +++ b/meta-yocto/recipes-kernel/linux/linux-yocto_2.6.37.bbappend @@ -3,11 +3,11 @@ KMACHINE_routerstationpro = "yocto/standard/routerstationpro" KMACHINE_mpc8315e-rdb = "yocto/standard/fsl-mpc8315e-rdb" KMACHINE_beagleboard = "yocto/standard/beagleboard" -SRCREV_machine_emenlow = "7dd88fc03db50b131e4a96e6af8036a836ccc300" -SRCREV_machine_atom-pc = "1ccece1d42a598fef0f5f9666c9c81315302c129" -SRCREV_machine_routerstationpro = "8b5f5129292bb218435ac9ffa1fb9943bdc7d456" -SRCREV_machine_mpc8315e-rdb = "dcf359635969abdbdd15f60b702ab17ed6174892" -SRCREV_machine_beagleboard = "9cb5c3fb1634e541cacceeb8c8cabe88afa5b080" +SRCREV_machine_emenlow = "16ee3992a267124d425533275ebba4e6b7ae50a2" +SRCREV_machine_atom-pc = "77c90b3cd111a160d845400b4180d436e4b554df" +SRCREV_machine_routerstationpro = "014b17dffa3447350ad8c7bf847e4aedfc0c3196" +SRCREV_machine_mpc8315e-rdb = "c0d1bf23f865fdd07839c2002ca85a4913f0e111" +SRCREV_machine_beagleboard = "bd97d3f257387a3659b5c2761b0d5323b65203c7" COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" COMPATIBLE_MACHINE_routerstationpro = "routerstationpro" -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
