* Re: [PATCH] fast-import: Allow filemodify to set the root
From: Ramkumar Ramachandra @ 2010-10-08 8:15 UTC (permalink / raw)
To: David Barr
Cc: Git Mailing List, Jonathan Nieder, Sverre Rabbelier,
Johannes Sixt
In-Reply-To: <1286448906-1424-1-git-send-email-david.barr@cordelta.com>
Hi David,
I'm sorry I didn't get the time to look at this earlier- just looked
at it now.
David Barr writes:
> Most git commands do their writing to the object db via the index and
> loose objects. When you just have a pile of trees you want to convert
> into commits, this is wasteful; for performance-critical operations
> like filter-branch --subdirectory-filter, one might want a sort of
> hash-object --batch-to-pack to write a pack directly.
>
> Fortunately we have fast-import (which is one of the only git commands
> that will write to a pack directly) but there is not an advertised way
> to tell fast-import to use a given tree for its commits. So in
> current git, one has the unpleasant choice of writing loose objects
> without parsing the trees or writing straight to pack but having to
> parse trees to do it.
>
> This patch changes that, by allowing
>
> M 040000 <tree id> ""
It can be a <dataref> in general: either a SHA1 or a tree mark.
> as a filemodify line in a commit to reset to a particular tree without
> any need to unpack it. For example,
>
> M 040000 4b825dc642cb6eb9a060e54bf8d69288fbee4904 ""
>
> is a synonym for the deleteall command.
>
> Commit-message-by: Jonathan Nieder <jrnieder@gmail.com>
> Signed-off-by: David Barr <david.barr@cordelta.com>
> ---
> fast-import.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
I applied and tried it out- it works as expected. Here's a patch for
the documentation and a test. You might want to put the test in a
separate patch (in preparation for Jonathan's t9300 cleanup series).
@Jonathan: What happened to your series cleaning up t9300?
Tested-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
-- 8< --
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 966ba4f..90a4666 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -524,6 +524,9 @@ start with double quote (`"`).
If an `LF` or double quote must be encoded into `<path>` shell-style
quoting should be used, e.g. `"path/with\n and \" in it"`.
+Additionally, in `040000` mode, `<path>` may also be an empty string
+(`""`) to specify the root of the tree.
+
The value of `<path>` must be in canonical form. That is it must not:
* contain an empty directory component (e.g. `foo//bar` is invalid),
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 7c05920..3c0cf05 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -875,6 +875,27 @@ test_expect_success \
compare_diff_raw expect actual'
test_expect_success \
+ 'N: copy root directory by tree hash' \
+ 'cat >expect <<-\EOF &&
+ :100755 000000 f1fb5da718392694d0076d677d6d0e364c79b0bc 0000000000000000000000000000000000000000 D file3/newf
+ :100644 000000 7123f7f44e39be127c5eb701e5968176ee9d78b1 0000000000000000000000000000000000000000 D file3/oldf
+ EOF
+ root=$(git rev-parse refs/heads/branch^0^{tree}) &&
+ cat >input <<-INPUT_END &&
+ commit refs/heads/N6
+ committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+ data <<COMMIT
+ copy root directory by tree hash
+ COMMIT
+
+ from refs/heads/branch^0
+ M 040000 $root ""
+ INPUT_END
+ git fast-import <input &&
+ git diff-tree -C --find-copies-harder -r N4 N6 >actual &&
+ compare_diff_raw expect actual'
+
+test_expect_success \
'N: modify copied tree' \
'cat >expect <<-\EOF &&
:100644 100644 fcf778cda181eaa1cbc9e9ce3a2e15ee9f9fe791 fcf778cda181eaa1cbc9e9ce3a2e15ee9f9fe791 C100 newdir/interesting file3/file5
> diff --git a/fast-import.c b/fast-import.c
> index 2317b0f..8f68a89 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1454,6 +1454,15 @@ static int tree_content_set(
> n = slash1 - p;
> else
> n = strlen(p);
> + if (!slash1 && !n) {
> + if (!S_ISDIR(mode))
> + die("Root cannot be a non-directory");
> + hashcpy(root->versions[1].sha1, sha1);
> + if (root->tree)
> + release_tree_content_recursive(root->tree);
> + root->tree = subtree;
Should there be a hashclr(root->versions[1].sha1) here? I saw it in
the other branches.
Looks good otherwise. I'm surprised fast-import didn't already have
this functionality.
-- Ram
^ permalink raw reply related
* [U-Boot] [PATCH] include/compiler.h: remove uint typedef for __MACH__
From: Wolfgang Denk @ 2010-10-08 8:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <E0A9E8C7-F2F2-40D7-A71F-40C92D2B8390@googlemail.com>
Dear =?iso-8859-1?Q?Andreas_Bie=DFmann?=,
In message <E0A9E8C7-F2F2-40D7-A71F-40C92D2B8390@googlemail.com> you wrote:
>
> >> include/compiler.h | 1 -
> >> 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > Applied, thanks.
> >
> > Best regards,
> >
> > Wolfgang Denk
>
> couldn't find this patch mainline. Where did it go?
commit 59336459042a5fccb2dda9cfbb592802c88f583d
Author: Andreas Bie?mann <andreas.devel@googlemail.com>
Date: Sat Sep 25 17:45:59 2010 +0200
include/compiler.h: remove uint typedef for __MACH__
See
http://git.denx.de/?p=u-boot.git;a=commit;h=59336459042a5fccb2dda9cfbb592802c88f583d
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
History is only a confused heap of facts.
-- Philip Earl of Chesterfield
^ permalink raw reply
* Re: Section mismatches in memblock
From: Ingo Molnar @ 2010-10-08 8:16 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Yinghai Lu, Benjamin Herrenschmidt, Thomas Gleixner, LKML
In-Reply-To: <4CABE739.8050001@kernel.org>
* H. Peter Anvin <hpa@kernel.org> wrote:
> On 10/05/2010 07:30 PM, H. Peter Anvin wrote:
> >
> > Wrong functions! Furhtermore, at least the tip tree definitely does not
> > have __init_memblock here:
> >
>
> Nevermind. I had missed that Ingo had put stuff into core/memblock on
> top of x86/memblock, just to be confusing.
Correct - we better keep it as a generic, non-x86 topic as it affects
other architectures. We can zap x86/memblock (it's fully contained in
core/memblock) so that it's not confusing.
Thanks,
Ingo
^ permalink raw reply
* Re: PATCH [0/4] perf: clean-up of power events API
From: Tejun Heo @ 2010-10-08 8:14 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Pierre Tardy, Mathieu Desnoyers, Thomas Renninger, Jean Pihet,
linux-trace-users, linux-pm, linux-perf-users, mingo, arjan, rjw,
linux-omap, Peter Zijlstra, Kevin Hilman, Steven Rostedt,
Frank Eigler, Masami Hiramatsu, Thomas Gleixner, Andrew Morton,
Linus Torvalds
In-Reply-To: <20101007155816.GA5351@nowhere>
Hello,
On 10/07/2010 05:58 PM, Frederic Weisbecker wrote:
> I really feel uncomfortable with this tracepoint/ABI problem....
> Mathieu suggested we start a user library that could handle these
> changes when they are really necessary.
>
> Thoughts?
>
> (Adding Tejun in Cc).
Given that tracepoints are supposed to make internal operation
visible. I don't think it's a good idea to make it part of fixed ABI.
Maybe some core part can be put in stone but I think things like
internal workqueue implementation should be changeable without
worrying about ABI issues.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 06/18] fs: Clean up inode reference counting
From: Christoph Hellwig @ 2010-10-08 8:15 UTC (permalink / raw)
To: Dave Chinner; +Cc: Christoph Hellwig, linux-fsdevel, linux-kernel
In-Reply-To: <20101008074643.GS4681@dastard>
On Fri, Oct 08, 2010 at 06:46:43PM +1100, Dave Chinner wrote:
> > Also any chance to get an assert under a debug option the the reference
> > count really is non-zero?
>
> For iref()? Sure, but I think WARN_ON_ONCE() is better for the moment,
> though.
I don't think a WARN_ON_ONCE is too helpful - there could be all kinds
of different filesystems having that issue. Also I think a plain
WARN_ON is cheaper than a WARN_ON_ONCE and this is a rather hot
codepath.
^ permalink raw reply
* Re: Configuration of nestedhvm
From: Keir Fraser @ 2010-10-08 8:15 UTC (permalink / raw)
To: Dong, Eddie; +Cc: Xen-devel
In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B22DBEA5AA@shsmsx501.ccr.corp.intel.com>
On 08/10/2010 08:56, "Dong, Eddie" <eddie.dong@intel.com> wrote:
>> I think patch#2 probably makes sense, but it should wait for the
>> patch that actually implements the per-domain config option, and
>> properly implements is_nestedhvm(), before going in.
>
> Yes, I am waiting for the take of that patch from Chris as well, but for some
> reason it is not in yet :(
>
> Either patch is taken first is fine. I can do the simple rebase.
The patch isn't in my queue. I assume it is largely tools-side and waiting
for a tools maintainer to do something with it, and/or Tim to Ack it.
-- Keir
^ permalink raw reply
* [U-Boot] [PATCH v2] lib/hashtable.c: add CONFIG_ENV_MIN_ENTRIES
From: Wolfgang Denk @ 2010-10-08 8:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <F2DA4AEA-D25A-4355-9727-715E47AE8AFB@googlemail.com>
Dear =?iso-8859-1?Q?Andreas_Bie=DFmann?=,
In message <F2DA4AEA-D25A-4355-9727-715E47AE8AFB@googlemail.com> you wrote:
>
> >> lib/hashtable.c | 12 ++++++++----
> >> 1 files changed, 8 insertions(+), 4 deletions(-)
> >
> > Applied, thanks.
> >
> > Best regards,
> >
> > Wolfgang Denk
>
> couldn't find this patch mainline. Where did it go?
commit fc5fc76bdad14425e3743e1494c9e444570df1be
Author: Andreas Bie?mann <andreas.devel@googlemail.com>
Date: Fri Oct 1 22:51:02 2010 +0200
lib/hashtable.c: add CONFIG_ENV_MIN_ENTRIES
See
http://git.denx.de/?p=u-boot.git;a=commit;h=fc5fc76bdad14425e3743e1494c9e444570df1be
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Quotation, n. The act of repeating erroneously the words of another.
The words erroneously repeated.
- Ambrose Bierce _The Devil's Dictionary_
^ permalink raw reply
* Re: RT on 2.6.34
From: Esben Haabendal @ 2010-10-08 8:07 UTC (permalink / raw)
To: walimis; +Cc: Sven-Thorsten Dietrich, linux-rt-users
In-Reply-To: <20101008020925.GB14157@ubuntu.mshome.net>
walimis <walimisdev@gmail.com> writes:
> On Tue, Oct 05, 2010 at 11:40:46PM -0700, Sven-Thorsten Dietrich wrote:
>> If I read this correctly, WR ported RT to 2.6.34.
>>
>> Anyone out there to confirm?
> Yes, it's true.
Ok, where do I download this from?
/Esben
^ permalink raw reply
* Re: PATCH [0/4] perf: clean-up of power events API
From: Tejun Heo @ 2010-10-08 8:14 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Thomas Gleixner, Andrew Morton, Pierre Tardy, Peter Zijlstra,
Linus Torvalds, mingo, Jean Pihet, Steven Rostedt,
linux-perf-users, linux-trace-users, Frank Eigler,
Mathieu Desnoyers, Masami Hiramatsu, linux-pm, linux-omap, arjan
In-Reply-To: <20101007155816.GA5351@nowhere>
Hello,
On 10/07/2010 05:58 PM, Frederic Weisbecker wrote:
> I really feel uncomfortable with this tracepoint/ABI problem....
> Mathieu suggested we start a user library that could handle these
> changes when they are really necessary.
>
> Thoughts?
>
> (Adding Tejun in Cc).
Given that tracepoints are supposed to make internal operation
visible. I don't think it's a good idea to make it part of fixed ABI.
Maybe some core part can be put in stone but I think things like
internal workqueue implementation should be changeable without
worrying about ABI issues.
Thanks.
--
tejun
^ permalink raw reply
* [Buildroot] Xterm: undefined reference to __longjmp_chk
From: Massimiliano Marretta @ 2010-10-08 8:13 UTC (permalink / raw)
To: buildroot
In-Reply-To: <4CAE0F33.5000305@marretta.com>
I resolved the problem by add to the makefile.in the CPPFLAGS
-U_FORTIFY_SOURCE.
There is possibility to add this flag by xterm.mk or is necessary to
create a patch ?
On 10/07/10 20:19, Massimiliano Marretta wrote:
> Hi,
>
> I'm using the buildroot 2010.08 version with crosstool-ng toolchain.
> The target is an x86 i686.
> I receive this error wit xterm compilation:
>
> charproc.o: In function `VTReset':
> charproc.c:(.text+0x2623): undefined reference to `__longjmp_chk'
> main.o: In function `hungtty':
> main.c:(.text+0x867): undefined reference to `__longjmp_chk'
> misc.o: In function `end_vt_mode':
> misc.c:(.text+0x3a3): undefined reference to `__longjmp_chk'
> misc.o: In function `end_tek_mode':
> misc.c:(.text+0x3c7): undefined reference to `__longjmp_chk'
> Tekproc.o: In function `Tinput':
> Tekproc.c:(.text+0x1336): undefined reference to `__longjmp_chk'
> collect2: ld returned 1 exit status
> make[1]: *** [xterm] Error 1
> make[1]: Leaving directory
> `/srv/source/buildroot-2010.08/output/build/xterm-259'
> make: ***
> [/srv/source/buildroot-2010.08/output/build/xterm-259/.stamp_built]
> Error 2
>
>
--
Massimiliano Marretta
Via Zuccola 11
41015 Nonantola (Mo) - Italy
tel: +39 347 5340305
skype: mmarretta
/mailto:max at marretta.com/
/web:www.marretta.com/ <http://www.marretta.com>
^ permalink raw reply
* [Bug 29833] radeon crashes kicad when using modeset
From: bugzilla-daemon @ 2010-10-08 8:13 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-29833-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=29833
--- Comment #13 from Fabio Pedretti <fabio.ped@libero.it> 2010-10-08 01:13:25 PDT ---
To see which mesa driver you are using try:
glxinfo | grep OpenGL
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [Buildroot] Xterm: undefined reference to __longjmp_chk
From: Massimiliano Marretta @ 2010-10-08 8:13 UTC (permalink / raw)
To: buildroot
In-Reply-To: <4CAE0F33.5000305@marretta.com>
I resolved the problem by add to the makefile.in the CPPFLAGS
-U_FORTIFY_SOURCE.
There is possibility to add this flag by xterm.mk or is necessary to
create a patch ?
On 10/07/10 20:19, Massimiliano Marretta wrote:
> Hi,
>
> I'm using the buildroot 2010.08 version with crosstool-ng toolchain.
> The target is an x86 i686.
> I receive this error wit xterm compilation:
>
> charproc.o: In function `VTReset':
> charproc.c:(.text+0x2623): undefined reference to `__longjmp_chk'
> main.o: In function `hungtty':
> main.c:(.text+0x867): undefined reference to `__longjmp_chk'
> misc.o: In function `end_vt_mode':
> misc.c:(.text+0x3a3): undefined reference to `__longjmp_chk'
> misc.o: In function `end_tek_mode':
> misc.c:(.text+0x3c7): undefined reference to `__longjmp_chk'
> Tekproc.o: In function `Tinput':
> Tekproc.c:(.text+0x1336): undefined reference to `__longjmp_chk'
> collect2: ld returned 1 exit status
> make[1]: *** [xterm] Error 1
> make[1]: Leaving directory
> `/srv/source/buildroot-2010.08/output/build/xterm-259'
> make: ***
> [/srv/source/buildroot-2010.08/output/build/xterm-259/.stamp_built]
> Error 2
>
>
--
Massimiliano Marretta
Via Zuccola 11
41015 Nonantola (Mo) - Italy
tel: +39 347 5340305
skype: mmarretta
/mailto:max at marretta.com/
/web:www.marretta.com/ <http://www.marretta.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101008/ecb527ad/attachment.html>
^ permalink raw reply
* The Missing Device
From: Nathan Caza @ 2010-10-08 8:12 UTC (permalink / raw)
To: linux-btrfs
In short here's what I know:
-When running out of free space i partitioned some free space on the
same device as the btrfs, and used 'btrfs add device'
-Everything worked ok
-Resized an ext2 filesystem and used fdisk to resize the partition
-Created a new partition with that free space (all occurring after
the 'new/added' space
-at some point i messed up the partition table
so at this point ive restored the partition table to the values i had
backed up (although the backup was on the lost partition so it was a
string search)
tried adjusting the table so the second 'device' partition is aligned
so the superblock that IS there is lined up at exactly 64MiB
The super block at 64kib is not there; all zeros; but the one at 64MiB
is there and the fs uuid matches the one on the original partition
All that i know is what I've been able to compare and deduce from
creating btrfs file systems and comparing the files..
it doesn't seem like anything was overwritten (all zeros at the
beginning); nothing should have been anyways only the partition table
was changed; no formatting/fs creation took place
I'm not sure if i can give any useful information but btrfs-debug-tree gives:
warning devid 2 not found already
btrfs-debug-tree: disk-io.c:741: open_ctree_fd: Assertion
`!(!tree_root->node)' failed.
btrfs fi sh:
Label: none uuid: 1a1297df-be3e-454e-a6b9-709397c803ff
Total devices 2 FS bytes used 14.37GB
devid 1 size 7.82GB used 7.82GB path /dev/sda7
*** Some devices missing
Btrfs Btrfs v0.19
Also: using ubuntu maverick RC
Linux nathan-laptop 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19
20:32:27 UTC 2010 x86_64 GNU/Linux
im assuming part of the tree is on the 2nd device that it cannot find;
I'm not at all sure what data would be useful or not; I'm not sure
what i did or if there was a bug; but ill try to get whatever would
help if anything;
as far as my data though I've been trying to make a dirty script to
recover files but as far as I've gotten was
figuring out where the super block is and finding uuid's;
using this as a chance to learn, albeit from a mistake
any place to start for building a recovery tool for btrfs would be
appreciated (technical disk format details); i need the experience
anyways
Any type of help, suggestions, or requests appreciated!
^ permalink raw reply
* [PATCH] i.MX35: use the correct IIM register to get CPU revision
From: Eric Bénard @ 2010-10-08 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286524957-30218-1-git-send-email-eric@eukrea.com>
Le 08/10/2010 10:02, Eric B?nard a ?crit :
> @@ -182,11 +184,7 @@
>
> #define MX35_PROD_SIGNATURE 0x1 /* For MX31 */
>
> -/* silicon revisions specific to i.MX35 */
> -#define MX35_CHIP_REV_1_0 0x1
> -#define MX35_CHIP_REV_2_0 0x2
> -
> -#define MX35_SYSTEM_REV_MIN MX35_CHIP_REV_1_0
> +#define MX35_SYSTEM_REV_MIN MX3x_CHIP_REV_1_0
> #define MX35_SYSTEM_REV_NUM 3
>
> #ifdef IMX_NEEDS_DEPRECATED_SYMBOLS
oops I made a mistake when importing your patches, the end of this one
shjould'nt be there.
Eric
^ permalink raw reply
* Re: [PATCH 18/18] fs: Reduce inode I_FREEING and factor inode disposal
From: Christoph Hellwig @ 2010-10-08 8:11 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-19-git-send-email-david@fromorbit.com>
> After the inode scalability work, there is not a big reason to batch
> up inodes to reclaim them, so we can dispose them as they are found
> from the LRU. With similar reasoning, we can do the same during
> unmount, completely removing the need for the dispose_list()
> function.
Given that two of the three callers already remove the inode from the
per-sb list what about doing that in the third also and stop bothering
with it in dispose_one_inode?
^ permalink raw reply
* Re: [PATCH v2] x86/therm_throt.c: Fix error handling in thermal_throttle_add_dev
From: Jean Delvare @ 2010-10-08 8:10 UTC (permalink / raw)
To: Fenghua Yu, Ingo Molnar
Cc: H Peter Anvin, Thomas Gleixner, Guenter Roeck, Jin Dongming,
Hidetoshi Seto, linux-kernel, lm-sensors
In-Reply-To: <1283905550-18571-1-git-send-email-fenghua.yu@intel.com>
On Tue, 7 Sep 2010 17:25:50 -0700, Fenghua Yu wrote:
> From: Fenghua Yu <fenghua.yu@intel.com>
>
> When sysfs_add_file_to_group fails, thermal_throttle_add_dev removes the
> created group and returns with the error code and the driver cleans up and
> returns with the error code. Thus the driver either installs all devices
> successfully or doesn't install any device at all.
>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> ---
> arch/x86/kernel/cpu/mcheck/therm_throt.c | 36 ++++++++++++++++++++++++++---
> 1 files changed, 32 insertions(+), 4 deletions(-)
>
Ingo, Fenghua, what happened to this patch? There was so much
discussion about it about the details that in the end nothing was done
and the actual bug in the code (missing curly braces) is still not
fixed while kernel 2.6.36 is about to be released. This is no good.
The original fix for the main bug was sent by Jin Dongming on August
26th, 2010:
http://lkml.org/lkml/2010/8/26/67
If we can't agree on how to handle errors, at least this easy patch (which
fixes the _success_ path) should be applied immediately.
> diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> index c2a8b26..5099e90 100644
> --- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
> +++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> @@ -211,19 +211,33 @@ static __cpuinit int thermal_throttle_add_dev(struct sys_device *sys_dev)
> if (err)
> return err;
>
> - if (cpu_has(c, X86_FEATURE_PLN))
> + if (cpu_has(c, X86_FEATURE_PLN)) {
> err = sysfs_add_file_to_group(&sys_dev->kobj,
> &attr_core_power_limit_count.attr,
> thermal_attr_group.name);
> - if (cpu_has(c, X86_FEATURE_PTS))
> + if (err)
> + goto error;
> + }
> +
> + if (cpu_has(c, X86_FEATURE_PTS)) {
> err = sysfs_add_file_to_group(&sys_dev->kobj,
> &attr_package_throttle_count.attr,
> thermal_attr_group.name);
> - if (cpu_has(c, X86_FEATURE_PLN))
> + if (err)
> + goto error;
> +
> + if (cpu_has(c, X86_FEATURE_PLN)) {
> err = sysfs_add_file_to_group(&sys_dev->kobj,
> &attr_package_power_limit_count.attr,
> thermal_attr_group.name);
> + if (err)
> + goto error;
> + }
> + }
>
> + return 0;
> +error:
> + sysfs_remove_group(&sys_dev->kobj, &thermal_attr_group);
> return err;
> }
>
> @@ -275,6 +289,7 @@ static struct notifier_block thermal_throttle_cpu_notifier __cpuinitdata =
> static __init int thermal_throttle_init_device(void)
> {
> unsigned int cpu = 0;
> + int i;
> int err;
>
> if (!atomic_read(&therm_throt_en))
> @@ -288,13 +303,26 @@ static __init int thermal_throttle_init_device(void)
> /* connect live CPUs to sysfs */
> for_each_online_cpu(cpu) {
> err = thermal_throttle_add_dev(get_cpu_sysdev(cpu));
> - WARN_ON(err);
> + if (err)
> + goto error;
> }
> #ifdef CONFIG_HOTPLUG_CPU
> mutex_unlock(&therm_cpu_lock);
> #endif
>
> return 0;
> +error:
> + WARN_ON(err);
> +
> + /* cleanup. */
> + for (i = 0; i < cpu; i++)
> + thermal_throttle_remove_dev(get_cpu_sysdev(i));
> +#ifdef CONFIG_HOTPLUG_CPU
> + mutex_unlock(&therm_cpu_lock);
> +#endif
> + unregister_hotcpu_notifier(&thermal_throttle_cpu_notifier);
> +
> + return err;
> }
> device_initcall(thermal_throttle_init_device);
>
--
Jean Delvare
^ permalink raw reply
* Re: [lm-sensors] [PATCH v2] x86/therm_throt.c: Fix error handling
From: Jean Delvare @ 2010-10-08 8:10 UTC (permalink / raw)
To: Fenghua Yu, Ingo Molnar
Cc: H Peter Anvin, Thomas Gleixner, Guenter Roeck, Jin Dongming,
Hidetoshi Seto, linux-kernel, lm-sensors
In-Reply-To: <1283905550-18571-1-git-send-email-fenghua.yu@intel.com>
On Tue, 7 Sep 2010 17:25:50 -0700, Fenghua Yu wrote:
> From: Fenghua Yu <fenghua.yu@intel.com>
>
> When sysfs_add_file_to_group fails, thermal_throttle_add_dev removes the
> created group and returns with the error code and the driver cleans up and
> returns with the error code. Thus the driver either installs all devices
> successfully or doesn't install any device at all.
>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> ---
> arch/x86/kernel/cpu/mcheck/therm_throt.c | 36 ++++++++++++++++++++++++++---
> 1 files changed, 32 insertions(+), 4 deletions(-)
>
Ingo, Fenghua, what happened to this patch? There was so much
discussion about it about the details that in the end nothing was done
and the actual bug in the code (missing curly braces) is still not
fixed while kernel 2.6.36 is about to be released. This is no good.
The original fix for the main bug was sent by Jin Dongming on August
26th, 2010:
http://lkml.org/lkml/2010/8/26/67
If we can't agree on how to handle errors, at least this easy patch (which
fixes the _success_ path) should be applied immediately.
> diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> index c2a8b26..5099e90 100644
> --- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
> +++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> @@ -211,19 +211,33 @@ static __cpuinit int thermal_throttle_add_dev(struct sys_device *sys_dev)
> if (err)
> return err;
>
> - if (cpu_has(c, X86_FEATURE_PLN))
> + if (cpu_has(c, X86_FEATURE_PLN)) {
> err = sysfs_add_file_to_group(&sys_dev->kobj,
> &attr_core_power_limit_count.attr,
> thermal_attr_group.name);
> - if (cpu_has(c, X86_FEATURE_PTS))
> + if (err)
> + goto error;
> + }
> +
> + if (cpu_has(c, X86_FEATURE_PTS)) {
> err = sysfs_add_file_to_group(&sys_dev->kobj,
> &attr_package_throttle_count.attr,
> thermal_attr_group.name);
> - if (cpu_has(c, X86_FEATURE_PLN))
> + if (err)
> + goto error;
> +
> + if (cpu_has(c, X86_FEATURE_PLN)) {
> err = sysfs_add_file_to_group(&sys_dev->kobj,
> &attr_package_power_limit_count.attr,
> thermal_attr_group.name);
> + if (err)
> + goto error;
> + }
> + }
>
> + return 0;
> +error:
> + sysfs_remove_group(&sys_dev->kobj, &thermal_attr_group);
> return err;
> }
>
> @@ -275,6 +289,7 @@ static struct notifier_block thermal_throttle_cpu_notifier __cpuinitdata > static __init int thermal_throttle_init_device(void)
> {
> unsigned int cpu = 0;
> + int i;
> int err;
>
> if (!atomic_read(&therm_throt_en))
> @@ -288,13 +303,26 @@ static __init int thermal_throttle_init_device(void)
> /* connect live CPUs to sysfs */
> for_each_online_cpu(cpu) {
> err = thermal_throttle_add_dev(get_cpu_sysdev(cpu));
> - WARN_ON(err);
> + if (err)
> + goto error;
> }
> #ifdef CONFIG_HOTPLUG_CPU
> mutex_unlock(&therm_cpu_lock);
> #endif
>
> return 0;
> +error:
> + WARN_ON(err);
> +
> + /* cleanup. */
> + for (i = 0; i < cpu; i++)
> + thermal_throttle_remove_dev(get_cpu_sysdev(i));
> +#ifdef CONFIG_HOTPLUG_CPU
> + mutex_unlock(&therm_cpu_lock);
> +#endif
> + unregister_hotcpu_notifier(&thermal_throttle_cpu_notifier);
> +
> + return err;
> }
> device_initcall(thermal_throttle_init_device);
>
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Fwd: Re: lxc-performance?
From: MALATTAR @ 2010-10-08 8:09 UTC (permalink / raw)
To: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
-------- Message original --------
Sujet: Re: lxc-performance
Date : Thu, 07 Oct 2010 16:56:05 +0200
De : MALATTAR <mouhannad.alattar-jI/kxupzh7HSLaPbPq81kw@public.gmane.org>
Pour : MALATTAR <mouhannad.alattar-jI/kxupzh7HSLaPbPq81kw@public.gmane.org>
Le 07/10/2010 16:43, MALATTAR a écrit :
> ------------------------------------------------------------------------
> 06.10.2010 23:41, MALATTAR ?????:
>
> >/ the container dora1, where i launch an instance of my IDS, does not take
> />/ more than 70 MB as memory even though the memory limit for it is much
> />/ bigger than this value,
> /
> How do you measure memory usage?
by using the command:
lxc-cgroup -n dora1 memory.usage_in_bytes
> What's in memory.max_usage_in_bytes of
> the container's cgroup?
executing the next command lxc-cgroup -n dora1 memory.max_usage_in_bytes
gave me 70193152 bytes
> --
> Mouhannad AlATTAR
> Doctorant à L'UFR Sciences,Techniques et Gestion de l'Industrie
> Pôle multimedia de Franche Comté - numerica
> 1, cours Leprince-Ringuet
> 25201 Montbéliard
> Fixe bureau : 03 81 99 47 87
> Portable : 06 16 71 05 10
>
>
--
Mouhannad AlATTAR
Doctorant à L'UFR Sciences,Techniques et Gestion de l'Industrie
Pôle multimedia de Franche Comté - numerica
1, cours Leprince-Ringuet
25201 Montbéliard
Fixe bureau : 03 81 99 47 87
Portable : 06 16 71 05 10
^ permalink raw reply
* Re: [PATCH 17/18] fs: icache remove inode_lock
From: Dave Chinner @ 2010-10-08 8:09 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <20101008080319.GC30902@infradead.org>
On Fri, Oct 08, 2010 at 04:03:19AM -0400, Christoph Hellwig wrote:
> On Fri, Oct 08, 2010 at 04:21:31PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > All the functionality that the inode_lock protected has now been
> > wrapped up in new independent locks and/or functionality. Hence the
> > inode_lock does not serve a purpose any longer and hence can now be
> > removed.
>
> Might be worth mentioning this also updates the locking / lock order
> documenation all over the place.
Ok.
>
> > --- a/Documentation/filesystems/Locking
> > +++ b/Documentation/filesystems/Locking
> > @@ -114,7 +114,7 @@ alloc_inode:
> > destroy_inode:
> > dirty_inode: (must not sleep)
> > write_inode:
> > -drop_inode: !!!inode_lock!!!
> > +drop_inode: !!!i_lock, sb_inode_list_lock!!!
>
> sb_inode_list_lock now is sb->s_inodes_lock, this also applies in a few
> other places.
>
>
> > +[mandatory]
> > + inode_lock is gone, replaced by fine grained locks. See fs/inode.c
> > +for details of what locks to replace inode_lock with in order to protect
> > +particular things. Most of the time, a filesystem only needs ->i_lock, which
> > +protects *all* the inode state and its membership on lists that was
> > +previously protected with inode_lock.
>
> Which list membership does i_lock protect?
Oops, I missed updating the documentation file. Will fix that up.
> > --- a/fs/notify/inode_mark.c
> > +++ b/fs/notify/inode_mark.c
> > @@ -22,7 +22,7 @@
> > #include <linux/module.h>
> > #include <linux/mutex.h>
> > #include <linux/spinlock.h>
> > -#include <linux/writeback.h> /* for inode_lock */
> > +#include <linux/writeback.h>
>
> Do we still need writeback.h here?
>
> > @@ -76,7 +76,7 @@
> > #include <linux/buffer_head.h>
> > #include <linux/capability.h>
> > #include <linux/quotaops.h>
> > -#include <linux/writeback.h> /* for inode_lock, oddly enough.. */
> > +#include <linux/writeback.h>
>
> Same here.
I'll check them and clean it up appropriately.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* RE: [PATCH] ARM: S5PV210: Fix build error on pm debug
From: Kukjin Kim @ 2010-10-08 8:08 UTC (permalink / raw)
To: 'Sangbeom Kim', linux-samsung-soc; +Cc: ben-linux
In-Reply-To: <1286430096-23111-1-git-send-email-sbkim73@samsung.com>
Sangbeom Kim wrote:
>
> This patch fixes build error by S3C2410 PM
> Suspend debug option due to undefined address
^^^^^
No need above blank?
Looks ok anyway...will apply.
> Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
> ---
> arch/arm/mach-s5pv210/include/mach/map.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach-
> s5pv210/include/mach/map.h
> index bd9afd5..9f2bee2 100644
> --- a/arch/arm/mach-s5pv210/include/mach/map.h
> +++ b/arch/arm/mach-s5pv210/include/mach/map.h
> @@ -57,6 +57,8 @@
>
> #define S5P_SZ_UART SZ_256
>
> +#define S3C_VA_UARTx(x) (S3C_VA_UART + ((x) *
> S3C_UART_OFFSET))
> +
> #define S5PV210_PA_SROMC (0xE8000000)
>
> #define S5PV210_PA_CFCON (0xE8200000)
> --
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCHv2] cpufreq for freescale mx51
From: yong.shen at linaro.org @ 2010-10-08 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286525307-1934-1-git-send-email-yong.shen@linaro.org>
From: Yong Shen <yong.shen@linaro.org>
it is tested on babbage 3.0
Signed-off-by: Yong Shen <yong.shen@linaro.org>
---
arch/arm/Kconfig | 6 +
arch/arm/mach-mx5/Kconfig | 1 +
arch/arm/mach-mx5/Makefile | 1 +
arch/arm/mach-mx5/board-mx51_babbage.c | 12 ++-
arch/arm/mach-mx5/clock-mx51.c | 24 ++++
arch/arm/mach-mx5/cpu.c | 2 +
arch/arm/mach-mx5/cpu_wp-mx51.c | 42 ++++++
arch/arm/mach-mx5/cpu_wp-mx51.h | 14 ++
arch/arm/plat-mxc/Makefile | 2 +
arch/arm/plat-mxc/cpufreq.c | 236 ++++++++++++++++++++++++++++++++
arch/arm/plat-mxc/include/mach/mxc.h | 20 +++-
11 files changed, 358 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-mx5/cpu_wp-mx51.c
create mode 100644 arch/arm/mach-mx5/cpu_wp-mx51.h
create mode 100644 arch/arm/plat-mxc/cpufreq.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d203b84..71a572a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1690,6 +1690,12 @@ if ARCH_HAS_CPUFREQ
source "drivers/cpufreq/Kconfig"
+config CPU_FREQ_IMX
+ tristate "CPUfreq driver for i.MX CPUs"
+ depends on ARCH_MXC && CPU_FREQ
+ help
+ This enables the CPUfreq driver for i.MX CPUs.
+
config CPU_FREQ_SA1100
bool
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 0848db5..7a621b4 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -5,6 +5,7 @@ config ARCH_MX51
default y
select MXC_TZIC
select ARCH_MXC_IOMUX_V3
+ select ARCH_HAS_CPUFREQ
comment "MX5 platforms:"
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 86c66e7..e2af3fb 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -5,6 +5,7 @@
# Object file lists.
obj-y := cpu.o mm.o clock-mx51.o devices.o
+obj-$(CONFIG_CPU_FREQ_IMX) += cpu_wp-mx51.o
obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
obj-$(CONFIG_MACH_MX51_3DS) += board-mx51_3ds.o
obj-$(CONFIG_MACH_EUKREA_CPUIMX51) += board-cpuimx51.o
diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c
index 6e384d9..2d2a052 100644
--- a/arch/arm/mach-mx5/board-mx51_babbage.c
+++ b/arch/arm/mach-mx5/board-mx51_babbage.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2009-2010 Freescale Semiconductor, Inc. All Rights Reserved.
* Copyright (C) 2009-2010 Amit Kucheria <amit.kucheria@canonical.com>
*
* The code contained herein is licensed under the GNU General Public
@@ -32,6 +32,7 @@
#include <asm/mach/time.h>
#include "devices.h"
+#include "cpu_wp-mx51.h"
#define BABBAGE_USB_HUB_RESET (0*32 + 7) /* GPIO_1_7 */
#define BABBAGE_USBH1_STP (0*32 + 27) /* GPIO_1_27 */
@@ -279,8 +280,17 @@ static struct sys_timer mxc_timer = {
.init = mx51_babbage_timer_init,
};
+static void __init fixup_mxc_board(struct machine_desc *desc, struct tag *tags,
+ char **cmdline, struct meminfo *mi)
+{
+#if defined(CONFIG_CPU_FREQ_IMX)
+ get_cpu_wp = mx51_get_cpu_wp;
+#endif
+}
+
MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board")
/* Maintainer: Amit Kucheria <amit.kucheria@canonical.com> */
+ .fixup = fixup_mxc_board,
.phys_io = MX51_AIPS1_BASE_ADDR,
.io_pg_offst = ((MX51_AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc,
.boot_params = PHYS_OFFSET + 0x100,
diff --git a/arch/arm/mach-mx5/clock-mx51.c b/arch/arm/mach-mx5/clock-mx51.c
index 6af69de..f23cfab 100644
--- a/arch/arm/mach-mx5/clock-mx51.c
+++ b/arch/arm/mach-mx5/clock-mx51.c
@@ -39,6 +39,8 @@ static struct clk ahb_clk;
static struct clk ipg_clk;
static struct clk usboh3_clk;
+DEFINE_SPINLOCK(clk_lock);
+
#define MAX_DPLL_WAIT_TRIES 1000 /* 1000 * udelay(1) = 1ms */
static int _clk_ccgr_enable(struct clk *clk)
@@ -342,6 +344,26 @@ static unsigned long clk_arm_get_rate(struct clk *clk)
return parent_rate / div;
}
+static int _clk_cpu_set_rate(struct clk *clk, unsigned long rate)
+{
+ u32 reg, cpu_podf;
+ unsigned long flags, parent_rate;
+
+ parent_rate = clk_get_rate(clk->parent);
+ cpu_podf = parent_rate / rate - 1;
+ /* use post divider to change freq */
+ spin_lock_irqsave(&clk_lock, flags);
+
+ reg = __raw_readl(MXC_CCM_CACRR);
+ reg &= ~MXC_CCM_CACRR_ARM_PODF_MASK;
+ reg |= cpu_podf << MXC_CCM_CACRR_ARM_PODF_OFFSET;
+ __raw_writel(reg, MXC_CCM_CACRR);
+
+ spin_unlock_irqrestore(&clk_lock, flags);
+
+ return 0;
+}
+
static int _clk_periph_apm_set_parent(struct clk *clk, struct clk *parent)
{
u32 reg, mux;
@@ -694,6 +716,7 @@ static struct clk periph_apm_clk = {
static struct clk cpu_clk = {
.parent = &pll1_sw_clk,
.get_rate = clk_arm_get_rate,
+ .set_rate = _clk_cpu_set_rate,
};
static struct clk ahb_clk = {
@@ -837,6 +860,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK("fsl-usb2-udc", "usb", usboh3_clk)
_REGISTER_CLOCK("fsl-usb2-udc", "usb_ahb", ahb_clk)
_REGISTER_CLOCK("imx-keypad.0", NULL, kpp_clk)
+ _REGISTER_CLOCK(NULL, "cpu_clk", cpu_clk)
};
static void clk_tree_init(void)
diff --git a/arch/arm/mach-mx5/cpu.c b/arch/arm/mach-mx5/cpu.c
index 2d37785..83add9c 100644
--- a/arch/arm/mach-mx5/cpu.c
+++ b/arch/arm/mach-mx5/cpu.c
@@ -22,6 +22,8 @@ static int cpu_silicon_rev = -1;
#define SI_REV 0x48
+struct cpu_wp *(*get_cpu_wp)(int *wp);
+
static void query_silicon_parameter(void)
{
void __iomem *rom = ioremap(MX51_IROM_BASE_ADDR, MX51_IROM_SIZE);
diff --git a/arch/arm/mach-mx5/cpu_wp-mx51.c b/arch/arm/mach-mx5/cpu_wp-mx51.c
new file mode 100644
index 0000000..51bde45
--- /dev/null
+++ b/arch/arm/mach-mx5/cpu_wp-mx51.c
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ */
+
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later@the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/types.h>
+#include <mach/hardware.h>
+
+static struct cpu_wp cpu_wp_auto[] = {
+ {
+ .pll_rate = 800000000,
+ .cpu_rate = 160000000,
+ .pdf = 4,
+ .mfi = 8,
+ .mfd = 2,
+ .mfn = 1,
+ .cpu_podf = 4,
+ .cpu_voltage = 850000,},
+ {
+ .pll_rate = 800000000,
+ .cpu_rate = 800000000,
+ .pdf = 0,
+ .mfi = 8,
+ .mfd = 2,
+ .mfn = 1,
+ .cpu_podf = 0,
+ .cpu_voltage = 1100000,},
+};
+
+struct cpu_wp *mx51_get_cpu_wp(int *wp)
+{
+ *wp = sizeof(cpu_wp_auto) / sizeof(struct cpu_wp);
+ return cpu_wp_auto;
+}
diff --git a/arch/arm/mach-mx5/cpu_wp-mx51.h b/arch/arm/mach-mx5/cpu_wp-mx51.h
new file mode 100644
index 0000000..8038b62
--- /dev/null
+++ b/arch/arm/mach-mx5/cpu_wp-mx51.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ */
+
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+extern struct cpu_wp *mx51_get_cpu_wp(int *wp);
diff --git a/arch/arm/plat-mxc/Makefile b/arch/arm/plat-mxc/Makefile
index 78d405e..0b8464f 100644
--- a/arch/arm/plat-mxc/Makefile
+++ b/arch/arm/plat-mxc/Makefile
@@ -16,6 +16,8 @@ obj-$(CONFIG_MXC_ULPI) += ulpi.o
obj-$(CONFIG_ARCH_MXC_AUDMUX_V1) += audmux-v1.o
obj-$(CONFIG_ARCH_MXC_AUDMUX_V2) += audmux-v2.o
obj-$(CONFIG_MXC_DEBUG_BOARD) += 3ds_debugboard.o
+# CPU FREQ support
+obj-$(CONFIG_CPU_FREQ_IMX) += cpufreq.o
ifdef CONFIG_SND_IMX_SOC
obj-y += ssi-fiq.o
obj-y += ssi-fiq-ksym.o
diff --git a/arch/arm/plat-mxc/cpufreq.c b/arch/arm/plat-mxc/cpufreq.c
new file mode 100644
index 0000000..9990ea8
--- /dev/null
+++ b/arch/arm/plat-mxc/cpufreq.c
@@ -0,0 +1,236 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ */
+
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/*
+ * A driver for the Freescale Semiconductor i.MXC CPUfreq module.
+ * The CPUFREQ driver is for controling CPU frequency. It allows you to change
+ * the CPU clock speed on the fly.
+ */
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/cpufreq.h>
+#include <linux/init.h>
+#include <linux/proc_fs.h>
+#include <linux/regulator/consumer.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <mach/hardware.h>
+#include <asm/setup.h>
+#include <mach/clock.h>
+#include <asm/cacheflush.h>
+#include <linux/hrtimer.h>
+
+static int cpu_freq_khz_min;
+static int cpu_freq_khz_max;
+static int arm_lpm_clk;
+static int arm_normal_clk;
+static int cpufreq_suspended;
+
+static struct clk *cpu_clk;
+static struct cpufreq_frequency_table *imx_freq_table;
+
+static int cpu_wp_nr;
+static struct cpu_wp *cpu_wp_tbl;
+
+static int set_cpu_freq(int freq)
+{
+ int ret = 0;
+ int org_cpu_rate;
+ int gp_volt = 0;
+ int i;
+
+ org_cpu_rate = clk_get_rate(cpu_clk);
+ if (org_cpu_rate == freq)
+ return ret;
+
+ for (i = 0; i < cpu_wp_nr; i++) {
+ if (freq == cpu_wp_tbl[i].cpu_rate)
+ gp_volt = cpu_wp_tbl[i].cpu_voltage;
+ }
+
+ if (gp_volt == 0)
+ return ret;
+
+ ret = clk_set_rate(cpu_clk, freq);
+ if (ret != 0) {
+ printk(KERN_DEBUG "cannot set CPU clock rate\n");
+ return ret;
+ }
+
+ return ret;
+}
+
+static int mxc_verify_speed(struct cpufreq_policy *policy)
+{
+ if (policy->cpu != 0)
+ return -EINVAL;
+
+ return cpufreq_frequency_table_verify(policy, imx_freq_table);
+}
+
+static unsigned int mxc_get_speed(unsigned int cpu)
+{
+ if (cpu)
+ return 0;
+
+ return clk_get_rate(cpu_clk) / 1000;
+}
+
+static int mxc_set_target(struct cpufreq_policy *policy,
+ unsigned int target_freq, unsigned int relation)
+{
+ struct cpufreq_freqs freqs;
+ int freq_Hz;
+ int ret = 0;
+ unsigned int index;
+
+ if (cpufreq_suspended) {
+ target_freq = clk_get_rate(cpu_clk) / 1000;
+ cpufreq_frequency_table_target(policy, imx_freq_table,
+ target_freq, relation, &index);
+ freq_Hz = imx_freq_table[index].frequency * 1000;
+
+ if (freq_Hz == arm_lpm_clk)
+ freqs.old = cpu_wp_tbl[cpu_wp_nr - 2].cpu_rate / 1000;
+ else
+ freqs.old = arm_lpm_clk / 1000;
+
+ freqs.new = freq_Hz / 1000;
+ freqs.cpu = 0;
+ freqs.flags = 0;
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+ return ret;
+ }
+
+ cpufreq_frequency_table_target(policy, imx_freq_table,
+ target_freq, relation, &index);
+ freq_Hz = imx_freq_table[index].frequency * 1000;
+
+ freqs.old = clk_get_rate(cpu_clk) / 1000;
+ freqs.new = freq_Hz / 1000;
+ freqs.cpu = 0;
+ freqs.flags = 0;
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+
+ if (freqs.old != freqs.new)
+ ret = set_cpu_freq(freq_Hz);
+
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+
+ return ret;
+}
+
+static int __init mxc_cpufreq_init(struct cpufreq_policy *policy)
+{
+ int ret;
+ int i;
+
+ printk(KERN_INFO "i.MXC CPU frequency driver\n");
+
+ if (policy->cpu != 0)
+ return -EINVAL;
+
+ cpu_clk = clk_get(NULL, "cpu_clk");
+ if (IS_ERR(cpu_clk)) {
+ printk(KERN_ERR "%s: failed to get cpu clock\n", __func__);
+ return PTR_ERR(cpu_clk);
+ }
+
+ /* Set the current working point. */
+ cpu_wp_tbl = get_cpu_wp(&cpu_wp_nr);
+
+ cpu_freq_khz_min = cpu_wp_tbl[0].cpu_rate / 1000;
+ cpu_freq_khz_max = cpu_wp_tbl[0].cpu_rate / 1000;
+
+ imx_freq_table = kmalloc(
+ sizeof(struct cpufreq_frequency_table) * (cpu_wp_nr + 1),
+ GFP_KERNEL);
+
+ for (i = 0; i < cpu_wp_nr; i++) {
+ imx_freq_table[i].index = i;
+ imx_freq_table[i].frequency =
+ cpu_wp_tbl[i].cpu_rate / 1000;
+
+ if ((cpu_wp_tbl[i].cpu_rate / 1000) < cpu_freq_khz_min)
+ cpu_freq_khz_min = cpu_wp_tbl[i].cpu_rate / 1000;
+
+ if ((cpu_wp_tbl[i].cpu_rate / 1000) > cpu_freq_khz_max)
+ cpu_freq_khz_max = cpu_wp_tbl[i].cpu_rate / 1000;
+ }
+
+ imx_freq_table[i].index = i;
+ imx_freq_table[i].frequency = CPUFREQ_TABLE_END;
+
+ policy->cur = clk_get_rate(cpu_clk) / 1000;
+ policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
+ policy->min = policy->cpuinfo.min_freq = cpu_freq_khz_min;
+ policy->max = policy->cpuinfo.max_freq = cpu_freq_khz_max;
+
+ arm_lpm_clk = cpu_freq_khz_min * 1000;
+ arm_normal_clk = cpu_freq_khz_max * 1000;
+
+ /* Manual states, that PLL stabilizes in two CLK32 periods */
+ policy->cpuinfo.transition_latency = 10;
+
+ ret = cpufreq_frequency_table_cpuinfo(policy, imx_freq_table);
+
+ if (ret < 0) {
+ clk_put(cpu_clk);
+ printk(KERN_ERR "%s: failed to register i.MXC CPUfreq\n",
+ __func__);
+ return ret;
+ }
+
+ cpufreq_frequency_table_get_attr(imx_freq_table, policy->cpu);
+ return 0;
+}
+
+static int mxc_cpufreq_exit(struct cpufreq_policy *policy)
+{
+ cpufreq_frequency_table_put_attr(policy->cpu);
+
+ /* Reset CPU to 665MHz */
+ set_cpu_freq(arm_normal_clk);
+ clk_put(cpu_clk);
+ return 0;
+}
+
+static struct cpufreq_driver mxc_driver = {
+ .flags = CPUFREQ_STICKY,
+ .verify = mxc_verify_speed,
+ .target = mxc_set_target,
+ .get = mxc_get_speed,
+ .init = mxc_cpufreq_init,
+ .exit = mxc_cpufreq_exit,
+ .name = "imx",
+};
+
+static int __devinit mxc_cpufreq_driver_init(void)
+{
+ return cpufreq_register_driver(&mxc_driver);
+}
+
+static void mxc_cpufreq_driver_exit(void)
+{
+ cpufreq_unregister_driver(&mxc_driver);
+}
+
+module_init(mxc_cpufreq_driver_init);
+module_exit(mxc_cpufreq_driver_exit);
+
+MODULE_AUTHOR("Freescale Semiconductor Inc. Yong Shen <yong.shen@linaro.org>");
+MODULE_DESCRIPTION("CPUfreq driver for i.MX");
+MODULE_LICENSE("GPL");
diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
index a790bf2..31df991 100644
--- a/arch/arm/plat-mxc/include/mach/mxc.h
+++ b/arch/arm/plat-mxc/include/mach/mxc.h
@@ -1,5 +1,5 @@
/*
- * Copyright 2004-2007 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2004-2010 Freescale Semiconductor, Inc. All Rights Reserved.
* Copyright (C) 2008 Juergen Beisert (kernel at pengutronix.de)
*
* This program is free software; you can redistribute it and/or
@@ -133,6 +133,24 @@ extern unsigned int __mxc_cpu_type;
# define cpu_is_mxc91231() (0)
#endif
+#ifndef __ASSEMBLY__
+
+struct cpu_wp {
+ u32 pll_reg;
+ u32 pll_rate;
+ u32 cpu_rate;
+ u32 pdr0_reg;
+ u32 pdf;
+ u32 mfi;
+ u32 mfd;
+ u32 mfn;
+ u32 cpu_voltage;
+ u32 cpu_podf;
+};
+
+extern struct cpu_wp *(*get_cpu_wp)(int *wp);
+#endif
+
#if defined(CONFIG_ARCH_MX3) || defined(CONFIG_ARCH_MX2)
/* These are deprecated, use mx[23][157]_setup_weimcs instead. */
#define CSCR_U(n) (IO_ADDRESS(WEIM_BASE_ADDR + n * 0x10))
--
1.6.3.3
^ permalink raw reply related
* cpufreq for freescale mx51
From: yong.shen at linaro.org @ 2010-10-08 8:08 UTC (permalink / raw)
To: linux-arm-kernel
Hope this time I can cover all the comments. :)
^ permalink raw reply
* Re: [PATCH 16/18] fs: Make iunique independent of inode_lock
From: Dave Chinner @ 2010-10-08 8:06 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <20101008075524.GB30902@infradead.org>
On Fri, Oct 08, 2010 at 03:55:24AM -0400, Christoph Hellwig wrote:
> > + hlist_bl_for_each_entry(inode, node, &b->head, i_hash) {
> > + if (inode->i_ino == ino && inode->i_sb == sb) {
>
> wouldn't it be more natural to test the sb first here?
Maybe, but I think an inode number match is less likely, so the
order it currently does the check results in less code being
executed on misses. I'll have a look at the rest of the code and do
whatever order they do.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* [PATCH 2/2] configure.in: don't rely on test -a, not all shells support it
From: Simon McVittie @ 2010-10-08 8:06 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1.1: Type: text/plain, Size: 572 bytes --]
Notably, /bin/sh in Debian and Ubuntu is dash, which doesn't.
---
configure.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.in b/configure.in
index e904956..c353759 100644
--- a/configure.in
+++ b/configure.in
@@ -119,7 +119,7 @@ if test "$versioned" = "yes"; then
major=`echo $xres | cut -d . -f 1`
minor=`echo $xres | cut -d . -f 2`
pass=0
- if test $major -eq 1 -a $minor -gt 3; then
+ if test $major -eq 1 && test $minor -gt 3; then
pass=1
else
if test $major -gt 1; then
--
1.7.1
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related
* [PATCH 1/2] Version-check libtool correctly when doing an out-of-tree build
From: Simon McVittie @ 2010-10-08 8:06 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1.1: Type: text/plain, Size: 967 bytes --]
libtool is only created at the end of ./configure, so it doesn't make
sense to grep it in ./configure (the check would always fail the first
time). However, ltmain.sh is copied into the ${srcdir} by libtoolize and
should be safe to check at any time that configure can be run.
Signed-off-by: Simon McVittie <smcv@debian.org>
---
configure.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.in b/configure.in
index abc4687..e904956 100644
--- a/configure.in
+++ b/configure.in
@@ -115,7 +115,7 @@ AC_ARG_WITH(versioned,
versioned="$withval", versioned="yes")
if test "$versioned" = "yes"; then
# it seems that GNU ld versions since 2.10 are not broken
- xres=`grep '^VERSION=' libtool | cut -d = -f 2 | cut -d \" -f 2`
+ xres=`grep '^VERSION=' ${srcdir}/ltmain.sh | cut -d = -f 2 | cut -d \" -f 2`
major=`echo $xres | cut -d . -f 1`
minor=`echo $xres | cut -d . -f 2`
pass=0
--
1.7.1
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.