lkml.org 
[lkml]   [2011]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectARM SMP startup question (regarding gic secondary i nit)
     I was looking at a some of the SMP code in the arm mach types. Inside 
    the platform_secondary_init function they all seem to follow the same
    basic procedure:

    //secondary core code//
    gic_secondary_init(0);
    spin_lock(&boot_lock);
    spin_unlock(&boot_lock);

    I'm porting to a board myself, so I copied that structure to get
    started. While the secondary processor is in the first bit of code, the
    boot processor is here:

    //boot core code//
    spin_lock(&boot_lock);
    while (time_before(jiffies, timeout));
    /*
    * now the secondary core is starting up let it run its
    * calibrations, then wait for it to finish
    */
    spin_unlock(&boot_lock);

    which causes a deadlock because jiffies isn't being incremented, and
    the boot cpu has a lock on boot_lock that the secondary processor needs
    to sync with. Upon closer inspection gic_secondary_init uses the
    following lines of code:

    /*
    * Deal with the banked PPI and SGI interrupts - disable all
    * PPI interrupts, ensure all SGI interrupts are enabled.
    */
    writel(0xffff0000, dist_base + GIC_DIST_ENABLE_CLEAR);
    writel(0x0000ffff, dist_base + GIC_DIST_ENABLE_SET);

    The timer for the scheduler seems to be attached via the GIC PPI
    interrupts. I guess it makes sense that we don't need a scheduler while
    a CPU is booting. The problem is that even ignoring platform (or should
    I say mach?) specific code that uses jiffies as timer and timeout code,
    core ARM files rely on it. For example, after disabling timer interrupts
    the secondary core gets to the calibrate_delay function, which also has
    the jiffy loops that never end. If I replace
    writel(0x0000ffff, dist_base + GIC_DIST_ENABLE_SET);
    with
    writel(0xffffffff, dist_base + GIC_DIST_ENABLE_SET);
    to avoid disabling the timer interrupts the system boots without any
    problems, and both cpus work happily together.

    I should note that I am NOT yet using local timers.

    This is actually by first post to the LKML, I hope that I've asked the
    right questions and made my points efficiently enough.

    I've read a few ARM related posts here, and I'm still not clear on what
    is meant by "pointless churn". I understand that it means code is
    constantly being changed with little to no effect on the kernel, but
    what code are people refering to?

    Thanks,
    -Chris



    \
     
     \ /
      Last update: 2011-03-31 20:41    [W:4.111 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site