[PATCH] ppc: L2 cache prefetch fixes on 745x
tree a43d483cf144eb0f770a6e2e8ac9f721965a7fa9 parent 8085ce084c0f0144c353963853f81486fc331120 author Kumar Gala [EMAIL PROTECTED] Wed, 31 Aug 2005 14:54:47 +1000 committer Linus Torvalds [EMAIL PROTECTED] Fri, 02 Sep 2005 00:52:29 -0700 [PATCH] ppc: L2 cache prefetch fixes on 745x We run into problems if we blindly enable L2 prefetching without checking that the L2 cache is actually enabled. Additionaly, if we disable the L2 cache we need to ensure that we disable L2 prefetching. Signed-off-by: Kumar Gala [EMAIL PROTECTED] Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] arch/ppc/kernel/cpu_setup_6xx.S |5 - arch/ppc/kernel/l2cr.S | 31 ++- 2 files changed, 34 insertions(+), 2 deletions(-) diff --git a/arch/ppc/kernel/cpu_setup_6xx.S b/arch/ppc/kernel/cpu_setup_6xx.S --- a/arch/ppc/kernel/cpu_setup_6xx.S +++ b/arch/ppc/kernel/cpu_setup_6xx.S @@ -249,8 +249,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_NO_DPM) sync isync - /* Enable L2 HW prefetch + /* Enable L2 HW prefetch, if L2 is enabled */ + mfspr r3,SPRN_L2CR + andis. r3,r3,[EMAIL PROTECTED] + beqlr mfspr r3,SPRN_MSSCR0 ori r3,r3,3 sync diff --git a/arch/ppc/kernel/l2cr.S b/arch/ppc/kernel/l2cr.S --- a/arch/ppc/kernel/l2cr.S +++ b/arch/ppc/kernel/l2cr.S @@ -156,6 +156,26 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) The bit moved on the 7450. / +BEGIN_FTR_SECTION + /* Disable L2 prefetch on some 745x and try to ensure +* L2 prefetch engines are idle. As explained by errata +* text, we can't be sure they are, we just hope very hard +* that well be enough (sic !). At least I noticed Apple +* doesn't even bother doing the dcbf's here... +*/ + mfspr r4,SPRN_MSSCR0 + rlwinm r4,r4,0,0,29 + sync + mtspr SPRN_MSSCR0,r4 + sync + isync + lis r4,[EMAIL PROTECTED] + dcbf0,r4 + dcbf0,r4 + dcbf0,r4 + dcbf0,r4 +END_FTR_SECTION_IFSET(CPU_FTR_SPEC7450) + /* TODO: use HW flush assist when available */ lis r4,0x0002 @@ -230,7 +250,16 @@ END_FTR_SECTION_IFSET(CPU_FTR_SPEC7450) orisr3,r3,0x8000 mtspr SPRN_L2CR,r3 sync - + + /* Enable L2 HW prefetch on 744x/745x */ +BEGIN_FTR_SECTION + mfspr r3,SPRN_MSSCR0 + ori r3,r3,3 + sync + mtspr SPRN_MSSCR0,r3 + sync + isync +END_FTR_SECTION_IFSET(CPU_FTR_SPEC7450) 4: /* Restore HID0[DPM] to whatever it was before */ - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix bug in ppc64 dynamic hugepage support
tree 7e4ce062242df4690c6711ae1274d76e8ef5fce9 parent 7eaa414ee86cda4c153002ed218b9a0ad17f7de1 author David Gibson [EMAIL PROTECTED] Wed, 31 Aug 2005 14:34:05 +1000 committer Linus Torvalds [EMAIL PROTECTED] Fri, 02 Sep 2005 00:48:20 -0700 [PATCH] Fix bug in ppc64 dynamic hugepage support In adjusting the logic for SLB miss for the dynamic hugepage stuff, I messed up the !CONFIG_HUGETLB_PAGE case, failing to set the SLB flags properly. This fixes it. It also streamlines the logic for the HUGETLB_PAGE case (removing a couple of branches) while we're at it. Booted, and roughly tested on POWER5 (with and without HUGETLB_PAGE), iSeries/RS64 (no hugepage available), and G5 (with and without HUGETLB_PAGE). Signed-off-by: David Gibson [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] arch/ppc64/mm/slb_low.S | 22 +- 1 files changed, 9 insertions(+), 13 deletions(-) diff --git a/arch/ppc64/mm/slb_low.S b/arch/ppc64/mm/slb_low.S --- a/arch/ppc64/mm/slb_low.S +++ b/arch/ppc64/mm/slb_low.S @@ -97,25 +97,21 @@ BEGIN_FTR_SECTION lhz r9,PACAHIGHHTLBAREAS(r13) srdir11,r3,(HTLB_AREA_SHIFT-SID_SHIFT) srd r9,r9,r11 - andi. r9,r9,1 - bne 5f + lhz r11,PACALOWHTLBAREAS(r13) + srd r11,r11,r3 + or r9,r9,r11 +END_FTR_SECTION_IFSET(CPU_FTR_16M_PAGE) +#endif /* CONFIG_HUGETLB_PAGE */ li r11,SLB_VSID_USER - cmpldi r3,16 - bge 6f - - lhz r9,PACALOWHTLBAREAS(r13) - srd r9,r9,r3 - andi. r9,r9,1 - - beq 6f - -5: li r11,SLB_VSID_USER|SLB_VSID_L +#ifdef CONFIG_HUGETLB_PAGE +BEGIN_FTR_SECTION + rldimi r11,r9,8,55 /* shift masked bit into SLB_VSID_L */ END_FTR_SECTION_IFSET(CPU_FTR_16M_PAGE) #endif /* CONFIG_HUGETLB_PAGE */ -6: ld r9,PACACONTEXTID(r13) + ld r9,PACACONTEXTID(r13) rldimi r3,r9,USER_ESID_BITS,0 9: /* r3 = protovsid, r11 = flags, r10 = esid_data, cr7 = KERNELBASE */ - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add missing select's to DVB_BUDGET_AV
tree d6a45b71753d97d85dc1bbd7dd7a095144a6c50f parent 6b39374a27eb4be7e9d82145ae270ba02ea90dc8 author Adrian Bunk [EMAIL PROTECTED] Wed, 31 Aug 2005 17:43:51 +0200 committer Linus Torvalds [EMAIL PROTECTED] Fri, 02 Sep 2005 00:43:33 -0700 [PATCH] Add missing select's to DVB_BUDGET_AV This fixes the following compile error: ... LD .tmp_vmlinux1 drivers/built-in.o: In function `frontend_init': budget-av.c:(.text+0xb9448): undefined reference to `tda10046_attach' budget-av.c:(.text+0xb9518): undefined reference to `tda10021_attach' drivers/built-in.o: In function `philips_tu1216_request_firmware': budget-av.c:(.text+0xb937b): undefined reference to `request_firmware' make: *** [.tmp_vmlinux1] Error 1 Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: Johannes Stezenbach [EMAIL PROTECTED] Acked-by: Michael Krufky [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/media/dvb/ttpci/Kconfig |3 +++ 1 files changed, 3 insertions(+) diff --git a/drivers/media/dvb/ttpci/Kconfig b/drivers/media/dvb/ttpci/Kconfig --- a/drivers/media/dvb/ttpci/Kconfig +++ b/drivers/media/dvb/ttpci/Kconfig @@ -102,6 +102,9 @@ config DVB_BUDGET_AV select VIDEO_DEV select VIDEO_SAA7146_VV select DVB_STV0299 + select DVB_TDA1004X + select DVB_TDA10021 + select FW_LOADER help Support for simple SAA7146 based DVB cards (so called Budget- or Nova-PCI cards) without onboard - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Couple of read-tree questions
On Wed, 31 Aug 2005, Junio C Hamano wrote: Daniel Barkalow [EMAIL PROTECTED] writes: Is there any current use for read-tree with multiple trees without -m or equivalent? I did not know it even allowed multiple trees without -m, but you are right. It does not seem to complain. I have never thought about using multiple trees without -m, and I do not remember hearing any plan nor purpose of using it to do something interesting from Linus. I think its allowing multiple trees without -m is simply a bug. I guess it was probably that its behavior was obvious and didn't require any extra code. It still follows entirely from one tree without -m, but it might be worth prohibiting unless someone has a reason to do it intentionally. Why does --emu23 use I+H for stage 2, rather than just I? Wouldn't this just reintroduce removed files? They are not removed files, at least in the original context. The original intention was that git was supposed to work without having _any_ files in the working tree. The reason why multi-tree read-tree has so many special cases that says must match *if* work file exists, is that not having a corresponding working file was supposed to be equivalent to having the file checked out *and* unmodified. But they'd not only be missing from the working tree but also from the (pre-read-tree) index, which should only happen, assuming the index came from read-tree H, if they were subsequently removed from the index. I'd understand treating index entries for files missing from the working tree as up to date. (The thread you mention seems to say that we accept entries being missing from the index as if they were unchanged, but I don't see a good reason for this; you'd be dealing with the full set in the index for the merge, even if you don't have a populated working tree) I do not think anybody currently uses --emu23. I did it because it has a potential of making the two-tree fast forward (which is used in git checkout to switch between branches) easier to manage when the working tree is dirty than doing straight two-tree merge, but that is just a theoretical potential never tested in the field. Frankly, I do not mind, and I do not think anybody else minds, too much if you need to break or remove emu23 if that would make your code clean-up and redoing read-tree easier. I should have asked sooner, then. :) There's a bunch of clutter to get it to work that I can remove if it's not actually necessary. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Couple of read-tree questions
Daniel Barkalow [EMAIL PROTECTED] writes: (The thread you mention seems to say that we accept entries being missing from the index as if they were unchanged, but I don't see a good reason for this; you'd be dealing with the full set in the index for the merge, even if you don't have a populated working tree) You are correct. I was wondering myself why *both* of us thought (or Linus *seemed* to be agreeing, at least to me) what I was referring to as I+H made any sense while re-reaing the thread. I should have asked sooner, then. :) There's a bunch of clutter to get it to work that I can remove if it's not actually necessary. Yeah, removal of dead code! Go wild, please. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Any plans to make export work?
Hi Y'all, I've been playing with export a bit, and it doesn't seem to work. Or at least it doesn't do what I think of as work-ing. I'm basically doing a git-export and trying to create a quilt series out of it. When you do a quilt push -a I get as far as: 06f81ea8ca09b880cadf101d7e23b500e9c164bc [PATCH] scsi: remove volatile from scsi data which doesn't apply as it (seems to) conflict with: 152587deb8903c0edf483a5b889f975bc6bea7e0 [PATCH] fix NMI lockup with CFQ scheduler Those two commits (and others) were merged by hand in: c46f2ffb9e7fce7208c2639790e1ade42e00b146 merge by hand (scsi_device.h) Export gives me a patch for the merge, but it a) appears to contain everything that was merged, not just the fixup-by-hand, and b) export spits it out after both of the commits which the merge merged - which is no good as quilt doesn't even get that far. I realise I'm trying to represent a DAG as a linear series of patches. But the merge order is a linear sequence of commits, and so it *should* be representable as a linear series of patches. I think. Any thoughts? cheers -- Michael Ellerman IBM OzLabs email: michael:ellerman.id.au inmsg: mpe:jabber.org wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person pgp7wto6cqJCz.pgp Description: PGP signature
[PATCH] unset CDPATH in git-clone
Hello,
A colleague was having problems with git clone. It seemed to work as
expected for me so I went into his environment to see what was causing
it to fail. I found that he had set the CDPATH environment variable to
something like '.:..:../..:$HOME'. Try this (using bash) and you'll see
the problem:
export CDPATH=.
git clone (anything local)
The function get_repo_base seems to break with this CDPATH.
Below is how I solved the problem for the short-term. Use it as you see
fit. I did not look into other commands to see if there are other
implications to using CDPATH.
Cheers,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: [EMAIL PROTECTED]
Fort Collins, CO 80525 home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---
git-clone-script |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
50e48b03a5a82bb1e4ca95ef4e04cafc39a96f79
diff --git a/git-clone-script b/git-clone-script
--- a/git-clone-script
+++ b/git-clone-script
@@ -5,6 +5,8 @@
#
# Clone a repository into a different directory that does not yet exist.
+unset CDPATH
+
usage() {
echo 2 * git clone [-l [-s]] [-q] [-u upload-pack] repo dir
exit 1
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reworked read-tree.
On Thu, 1 Sep 2005, Junio C Hamano wrote: Daniel, I do not know what your current status is, but I think you need something like this. Yup, I forgot to actually test that functionality. --- diff --git a/tree.c b/tree.c --- a/tree.c +++ b/tree.c @@ -224,10 +224,12 @@ struct tree *parse_tree_indirect(const u if (obj-type == tree_type) return (struct tree *) obj; else if (obj-type == commit_type) - return ((struct commit *) obj)-tree; + obj = (struct object *)(((struct commit *) obj)-tree); obj = ((struct commit *) obj)-tree-object; Multiple sequential casts always bother me, and we do actually have a field for this. else if (obj-type == tag_type) - obj = ((struct tag *) obj)-tagged; + obj = deref_tag(obj); Shouldn't be necessary (once you've got the parse_object below); we're already in a loop dereferencing things. else return NULL; + if (!obj-parsed) + parse_object(obj-sha1); } while (1); } - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Junio C Hamano wrote: Tim Ottinger [EMAIL PROTECTED] writes: So when this gets all settled, will we see a lot of tool renaming? I personally do not see it coming. Any particular one you have in mind? git-update-cache for instance? I am not sure which 'cache' commands need to be 'index' now. -- ... either 'way ahead of the game, or 'way out in left field. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk with hyperspace support
On 8/30/05, Paul Mackerras [EMAIL PROTECTED] wrote: Try now... :) It also makes the current graph line thicker now, so it's easier to pick out where the line you clicked on goes. That's a fine feature :) BTW, did you sometimes notice lines you can't click at all? An example is the red line on the most left side of the graph by SHA 66129f88c4cc719591f687e5c8c764fe9d3e437a. It goes from blue up-arrow through green left bump to the grey down-arrow (on my system in the kernel tree). Clicking on the blue arrow (on the line, not the arrow itself) will turn the blue line stricken- through with the red line (a bold blue line with a red streak inside), the next click leaves me with with just bold blue line and broken red line above it. It's on Gentoo's Tcl/Tk 8.4.9. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk with hyperspace support
On Thu, September 1, 2005 4:10 pm, Alex Riesen said: That's a fine feature :) BTW, did you sometimes notice lines you can't click at all? An example is the red line on the most left side of the graph by SHA 66129f88c4cc719591f687e5c8c764fe9d3e437a. It goes from blue up-arrow through green left bump to the grey down-arrow (on my system in the kernel tree). Clicking on the blue arrow (on the line, not the arrow itself) will turn the blue line stricken- through with the red line (a bold blue line with a red streak inside), the next click leaves me with with just bold blue line and broken red line above it. For what it's worth, everything near that SHA1 works here as expected. Although I wasn't able to follow what you meant by blue up-arrow through green left bump... etc. But all the lines respond to being clicked and all the arrow heads in that area properly jump to their corresponding commit. That's with the latest checked out version of git and tcl/tk 8.4.9 as well. Sean - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any plans to make export work?
Michael Ellerman [EMAIL PROTECTED] writes: I realise I'm trying to represent a DAG as a linear series of patches. But the merge order is a linear sequence of commits, and so it *should* be representable as a linear series of patches. I think. Any thoughts? All true, and more. It does not show the initial import so you cannot bootstrap from an emptiness. git-export is among one of the things that were there before all the modern core features were invented (especially git-rev-list, let alone --merge-order flag to it) and could use an overhaul. I would script around rev-list --merge-order and diff-tree instead of hacking on that C code if I were doing it myself. But we need to define what we _want_ to see first. Here is a simple example: --- B -- C -- D / / O --- A --- The original O forked into branch A and B, merged at C and then continued on to D. What the current (admittedly ancient) 'git export' gives is: commit object O diff between void and O should be given but it doesn't. commit object A diff O A commit object B diff O B commit object C diff A C commit object D diff C D I just noticed that diff between B and C is not shown. Come to think of it, this is _not_ a bug (unlike the initial import not showing which I think is just a bug). The purpose of export is to give you everything that lets you recreate each tree associated with all commits and their ancestry information, so as long as you know C is a child of A and B, enough information to get trees A and B, and diff between A and C, diff between B and C is simply redundant. So, in short, export is perfect if we fix it to show the initial import. It just is not designed for doing whatever you are trying to do with its output. To be usable in your quilt workflow, what output would we want? Off the top of my head, I can think of this: commit object O diff between void and O commit object A diff between O and A commit object B diff between O and B commit object C diff between A and C diff between B and C commit object D diff between C and D Is this what you can use? If you can live with something like the above, 'git whatchanged -p -m --merge-order --root' would give you exactly that in a reverse order. It would give you: commit object D diff between C and D commit object C diff between A and C diff between B and C commit object B diff between O and B commit object A diff between O and A commit object O diff between void and O You earlier said diff between (automerged A+B) and C, but the former is not something git even records, so you have to compute it yourself from the given information, if you really want it. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please pull ppc64-2.6.git
Russell King [EMAIL PROTECTED] writes: Is the expected filesystem layout documented somewhere online (_external_ to the source code) ? There already was a sketchy description in git(7), at http://www.kernel.org/pub/software/scm/git/docs/ I've updated it a bit to describe the current status; please look for File/Directory Structure section of the above URL. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Tim Ottinger [EMAIL PROTECTED] writes: git-update-cache for instance? I am not sure which 'cache' commands need to be 'index' now. Logically you are right, but I suspect that may not fly well in practice. Too many of us have already got our fingers wired to type cache, and the glossary is there to describe both cache and index. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
