Eric Lee / smarc-fsl-linux-kernel

05 Mar, 2007

1 commit

  • 9432f9680   sh: Clear UBC when not in use. ... Browse Code »

    This takes care of tearing down the UBC so it's not inadvertently
    left configured at the next context switch time. Failure to do
    this results in spurious SIGTRAPs in certain debug sequences.

    Signed-off-by: Stuart Menefy
    Signed-off-by: Paul Mundt

    Stuart Menefy
     

13 Feb, 2007

1 commit

14 Dec, 2006

1 commit

  • 8a102eed9   [PATCH] PM: Fix SMP races in the freezer ... Browse Code »

    Currently, to tell a task that it should go to the refrigerator, we set the
    PF_FREEZE flag for it and send a fake signal to it. Unfortunately there
    are two SMP-related problems with this approach. First, a task running on
    another CPU may be updating its flags while the freezer attempts to set
    PF_FREEZE for it and this may leave the task's flags in an inconsistent
    state. Second, there is a potential race between freeze_process() and
    refrigerator() in which freeze_process() running on one CPU is reading a
    task's PF_FREEZE flag while refrigerator() running on another CPU has just
    set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it. If
    the refrigerator wins the race, freeze_process() will state that PF_FREEZE
    hasn't been set for the task and will set it unnecessarily, so the task
    will go to the refrigerator once again after it's been thawed.

    To solve first of these problems we need to stop using PF_FREEZE to tell
    tasks that they should go to the refrigerator. Instead, we can introduce a
    special TIF_*** flag and use it for this purpose, since it is allowed to
    change the other tasks' TIF_*** flags and there are special calls for it.

    To avoid the freeze_process()-refrigerator() race we can make
    freeze_process() to always check the task's PF_FROZEN flag after it's read
    its "freeze" flag. We should also make sure that refrigerator() will
    always reset the task's "freeze" flag after it's set PF_FROZEN for it.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek
    Cc: Russell King
    Cc: David Howells
    Cc: Andi Kleen
    Cc: "Luck, Tony"
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Paul Mundt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rafael J. Wysocki
     

06 Dec, 2006

1 commit

  • 510c72ad2   sh: Fixup various PAGE_SIZE == 4096 assumptions. ... Browse Code »

    There were a number of places that made evil PAGE_SIZE == 4k
    assumptions that ended up breaking when trying to play with
    8k and 64k page sizes, this fixes those up.

    The most significant change is the way we load THREAD_SIZE,
    previously this was done via:

    mov #(THREAD_SIZE >> 8), reg
    shll8 reg

    to avoid a memory access and allow the immediate load. With
    a 64k PAGE_SIZE, we're out of range for the immediate load
    size without resorting to special instructions available in
    later ISAs (movi20s and so on). The "workaround" for this is
    to bump up the shift to 10 and insert a shll2, which gives a
    bit more flexibility while still being much cheaper than a
    memory access.

    Signed-off-by: Paul Mundt

    Paul Mundt
     

27 Sep, 2006

5 commits

27 Mar, 2006

1 commit

  • 6ecf66ae4   [PATCH] bitops: sh: make thread_info.flags an unsigned long ... Browse Code »

    The test_bit() routines are defined to work on a pointer to unsigned long.
    But thread_info.flags is __u32 (unsigned int) on sh and it is passed to flag
    set/clear/test wrappers in include/linux/thread_info.h. So the compiler will
    print warnings.

    This patch changes to unsigned long instead.

    Signed-off-by: Akinobu Mita
    Cc: Paul Mundt
    Cc: Kazumoto Kojima
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

13 Jan, 2006

1 commit

24 Jun, 2005

1 commit

  • dcd497f99   [PATCH] streamline preempt_count type across archs ... Browse Code »

    The preempt_count member of struct thread_info is currently either defined
    as int, unsigned int or __s32 depending on arch. This patch makes the type
    of preempt_count an int on all archs.

    Having preempt_count be an unsigned type prevents the catching of
    preempt_count < 0 bugs, and using int on some archs and __s32 on others is
    not exactely "neat" - much nicer when it's just int all over.

    A previous version of this patch was already ACK'ed by Robert Love, and the
    only change in this version of the patch compared to the one he ACK'ed is
    that this one also makes sure the preempt_count member is consistently
    commented.

    Signed-off-by: Jesper Juhl
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jesper Juhl
     

29 May, 2005

1 commit

  • 37053cc84   [PATCH] sh: PREEMPT_ACTIVE fix ... Browse Code »

    Port Paulus's ppc64 fix to sh:

    When the generic IRQ stuff went in, it seems that HARDIRQ_BITS got bumped
    from 9 (for ppc64) up to 12. Consequently, the PREEMPT_ACTIVE bit is now
    within HARDIRQ_MASK, and I get in_interrupt() falsely returning true when
    PREEMPT_ACTIVE is set, and thus a BUG_ON tripping in arch/ppc64/mm/tlb.c.

    Signed-off-by: Paul Mundt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Mundt
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds