SMP support for XLR processors.
C. Jayachandran
c.jayachandran at gmail.com
Wed Apr 21 04:54:11 UTC 2010
On Wed, Apr 21, 2010 at 3:26 AM, M. Warner Losh <imp at bsdimp.com> wrote:
> In message: <l2tdffe84831004201436nf3e9fb18q652ccb3142e5e4f7 at mail.gmail.com>
> Neel Natu <neelnatu at gmail.com> writes:
> : Hi JC,
> :
> : On Sat, Apr 17, 2010 at 3:40 PM, C. Jayachandran
> : <c.jayachandran at gmail.com> wrote:
> : > I've a set of initial patches to enable SMP for RMI processors. It
> : > comes up in multi-user with 32 CPUs. I could do buildworld before I
> : > updated to HEAD - with head there is a hang during buildworld which
> : > I'm looking at, but I think the initial work can be checked in.
> : >
> : > Neel, can you have a look at the first two patches - one is to enable
> : > ULE scheduler and the second one is to move platform_init_ap to
> : > slightly later in the initialization sequence.
> : >
> : > The patches are :
> : > 1. mips-ule-support.patch
> : > - Enable ULE scheduler for MIPS
> : >
> : > 2. mips-smp-move-platform.patch
> : > - We need a hook to setup message ring and its interrupts, we use
> : > platform_init_ap now, and move it be called later for XLR
> : >
> :
> : I would like to see us move away from #ifdef TARGET_FOO in files under
> : mips/mips as much as possible. I think that is achieved easily in this
> : instance.
> :
> : How about we create a function platform_ap_enable_interrupts() that is
> : called from smp_init_secondary()? This function will be defined for
> : each platform.
> :
> : In the common case this function will simply call
> : mips_ap_enable_interrupts() that encapsulates the logic that we
> : currently have to setup interrupt masks for clock and ipi interrupts
> : in the status register. In the XLR case however it can do something
> : different.
> :
> : Ditto about the #ifdef TARGET_XLR_XLS in mpboot.S. You can simply have
> : an empty platform_init_ap() for XLR.
>
> In general, I'd love to see the TARGET_xxx stuff die entirely in the
> mips tree. That's a hack inherited from the Octeon port. There's
> other mechanisms that are better suited for this stuff...
Agree with you and Neel on this here. That explains why status
register handling for Octeon is the most common ifdef :)
JC.
More information about the freebsd-mips
mailing list