From: Sebastian Siewior <bigeasy@linutronix.de>
As the subject says this patch adds the support for kernel preemption
on m68knommu Coldfire. I thing the same changes could be applied to
68360 & 68328 but since I don't have the HW for testing, I don't touch it.Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---diff -Naurp linux-2.6.25/arch/m68knommu/kernel/asm-offsets.c linux-2.6.25-uc0/arch/m68knommu/kernel/asm-offsets.c
--- linux-2.6.25/arch/m68knommu/kernel/asm-offsets.c 2008-04-17 12:49:44.000000000 +1000
+++ linux-2.6.25-uc0/arch/m68knommu/kernel/asm-offsets.c 2008-03-28 15:29:06.000000000 +1000
@@ -91,6 +91,7 @@ int main(void)
DEFINE(TI_TASK, offsetof(struct thread_info, task));
DEFINE(TI_EXECDOMAIN, offsetof(struct thread_info, exec_domain));
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
+ DEFINE(TI_PREEMPTCOUNT, offsetof(struct thread_info, preempt_count));
DEFINE(TI_CPU, offsetof(struct thread_info, cpu));return 0;
diff -Naurp linux-2.6.25/arch/m68knommu/platform/coldfire/entry.S linux-2.6.25-uc0/arch/m68knommu/platform/coldfire/entry.S
--- linux-2.6.25/arch/m68knommu/platform/coldfire/entry.S 2008-04-17 12:49:44.000000000 +1000
+++ linux-2.6.25-uc0/arch/m68knommu/platform/coldfire/entry.S 2008-05-01 11:58:21.000000000 +1000
@@ -106,6 +106,22 @@ ret_from_exception:
btst #5,%sp@(PT_SR) /* check if returning to kernel */
jeq Luser_return /* if so, skip resched, signals */+#ifdef CONFIG_PREEMPT
+ movel %sp,%d1 /* get thread_info pointer */
+ andl #-THREAD_SIZE,%d1 /* at base of kernel stack */
+ movel %d1,%a0
+ movel %a0@(TI_FLAGS),%d1 /* get thread_info->flags */
+ andl #_TIF_NEED_RESCHED,%d1
+ jeq Lkernel_return
+
+ movel %a0@(TI_PREEMPTCOUNT),%d1
+ cmpl #0,%d1
+ jne Lkernel_return
+
+ pea Lkernel_return
+ jmp preempt_schedule_irq /* preempt the kernel */
+#endif
+
Lkernel_return:
moveml %sp@,%d1-%d5/%a0-%a2
lea %sp@(32),%sp /* space fo...
On Thu, 1 May 2008 12:16:29 +1000
Please find a way to get your patch queue into linux-next so that others
get some visibility into what you're brewing earlier than
last-day-of-the-merge-window?Also, when emailing patches like this I do think that it's best that they
be sequence-numbered, even if they are all non-overlapping and unrelated.
Because it allows the recipient to check that none got lost.Thanks.
--
Hi Andrew,
Ok.
Regards
Greg------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
--
Sebastian
--
Yup. Examples:
ftp://ftp.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/
http://ozlabs.org/~rusty/kernel/rr-latest
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-0...Note how you can publish subsets of your patchset by bracketing them with
"# MM_PATCHES_START" and "# MM_PATCHES_END" for -mm, and "#
NEXT_PATCHES_START" and "# NEXT_PATCHES_END" for linux-next.--
Hi Andrew,
I decided to go the git route.
Here is a git tree for the collection of patches for the m68knommu
architecture that I intend for the 2.6.27 merge window.git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-linus
I have created a general uclinux changes git tree as well,
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/uclinux.git for-linus
though currently I have nothing queued for that.
Regards
Greg------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
--
Great, thanks. But can we get them into linux-next please? I'll pick
them up via that route.--
Hi Greg,
nus
This tree currently has no for-linus branch. You should create one (even
if it just a subset of Linus' tree). I've added it using its master
branch for now, please let me know when it is fixed.Also, these branches would normally be called for-next. Most people keep
for-linus for bug fixes for the current release. If you decide to change
the branch name, just let me know.Repeat of the rules for linux-next: anything included must have been
posted somewhere appropriate, reviewed and unit tested (i.e. your treeDone.
--=20
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Hi Stephen,
Ok, done too. Branches named for-next exist in both. The patches
on the for-linus branch in the m68knommu.git are now on the
for-next branch.Do I need to send a request to Linus to pull this into his
tree during the next merge window? Or will it migrate upThanks
Greg------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
--
Hi Greg,
Andrew has answered these.
--=20
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Nope, linux-next is a testing tree only.
--
| Artem Bityutskiy | [PATCH 10/44 take 2] [UBI] debug unit implementation |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Trent Piepho | [PATCH] [POWERPC] Improve (in|out)_beXX() asm code |
| Dave Young | Re: Linux v2.6.24-rc1 |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Linus Torvalds | Re: [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
