2.6.25-mm1 - Kernel

This is a discussion on 2.6.25-mm1 - Kernel ; On Mon, 28 Apr 2008 20:06:51 -0700 Andrew Morton wrote: > On Mon, 21 Apr 2008 17:02:30 -0400 Andres Salomon wrote: > > > + if (!is_geode() || geode_has_vsa2()) > > geode_has_vsa2() is a fairly expensive-looking function and afacit only ...

+ Reply to Thread
Page 6 of 6 FirstFirst ... 4 5 6
Results 101 to 105 of 105

Thread: 2.6.25-mm1

  1. [PATCH] x86: GEODE: cache results from geode_has_vsa2() and uninline

    On Mon, 28 Apr 2008 20:06:51 -0700
    Andrew Morton wrote:

    > On Mon, 21 Apr 2008 17:02:30 -0400 Andres Salomon wrote:
    >
    > > + if (!is_geode() || geode_has_vsa2())

    >
    > geode_has_vsa2() is a fairly expensive-looking function and afacit only
    > needs to be evaluated once per boot. Perhaps we should cache it somewhere?
    >


    How about this?






    This moves geode_has_vsa2 into a .c file, caches the result we get from
    the VSA virtual registers, and causes the function to no longer be inline.

    Signed-off-by: Andres Salomon
    ---
    arch/x86/kernel/geode_32.c | 19 +++++++++++++++++++
    include/asm-x86/geode.h | 11 +----------
    2 files changed, 20 insertions(+), 10 deletions(-)

    diff --git a/arch/x86/kernel/geode_32.c b/arch/x86/kernel/geode_32.c
    index 9dad6ca..1cb8225 100644
    --- a/arch/x86/kernel/geode_32.c
    +++ b/arch/x86/kernel/geode_32.c
    @@ -161,6 +161,25 @@ void geode_gpio_setup_event(unsigned int gpio, int pair, int pme)
    }
    EXPORT_SYMBOL_GPL(geode_gpio_setup_event);

    +static int has_vsa2 = -1;
    +
    +int geode_has_vsa2(void)
    +{
    + if (has_vsa2 == -1) {
    + /*
    + * The VSA has virtual registers that we can query for a
    + * signature.
    + */
    + outw(VSA_VR_UNLOCK, VSA_VRC_INDEX);
    + outw(VSA_VR_SIGNATURE, VSA_VRC_INDEX);
    +
    + has_vsa2 = (inw(VSA_VRC_DATA) == VSA_SIG);
    + }
    +
    + return has_vsa2;
    +}
    +EXPORT_SYMBOL_GPL(geode_has_vsa2);
    +
    static int __init geode_southbridge_init(void)
    {
    if (!is_geode())
    diff --git a/include/asm-x86/geode.h b/include/asm-x86/geode.h
    index 7154dc4..8a53bc8 100644
    --- a/include/asm-x86/geode.h
    +++ b/include/asm-x86/geode.h
    @@ -185,16 +185,7 @@ static inline int is_geode(void)
    return (is_geode_gx() || is_geode_lx());
    }

    -/*
    - * The VSA has virtual registers that we can query for a signature.
    - */
    -static inline int geode_has_vsa2(void)
    -{
    - outw(VSA_VR_UNLOCK, VSA_VRC_INDEX);
    - outw(VSA_VR_SIGNATURE, VSA_VRC_INDEX);
    -
    - return (inw(VSA_VRC_DATA) == VSA_SIG);
    -}
    +extern int geode_has_vsa2(void);

    /* MFGPTs */

    --
    1.5.5

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] x86: GEODE: cache results from geode_has_vsa2() and uninline

    On Tue, 29 Apr 2008 01:32:13 -0400
    Andres Salomon wrote:

    > On Mon, 28 Apr 2008 20:06:51 -0700
    > Andrew Morton wrote:
    >
    > > On Mon, 21 Apr 2008 17:02:30 -0400 Andres Salomon wrote:
    > >
    > > > + if (!is_geode() || geode_has_vsa2())

    > >
    > > geode_has_vsa2() is a fairly expensive-looking function and afacit only
    > > needs to be evaluated once per boot. Perhaps we should cache it somewhere?
    > >

    >
    > How about this?
    >


    Looks sane. Although one wonders if it should be cached as one of the
    standard x86 feature bit thingies which show up in /proc/cpuinfo's 'flags'
    field.

    > +static int has_vsa2 = -1;
    > +
    > +int geode_has_vsa2(void)
    > +{
    > + if (has_vsa2 == -1) {
    > + /*
    > + * The VSA has virtual registers that we can query for a
    > + * signature.
    > + */
    > + outw(VSA_VR_UNLOCK, VSA_VRC_INDEX);
    > + outw(VSA_VR_SIGNATURE, VSA_VRC_INDEX);
    > +
    > + has_vsa2 = (inw(VSA_VRC_DATA) == VSA_SIG);
    > + }
    > +
    > + return has_vsa2;
    > +}
    > +EXPORT_SYMBOL_GPL(geode_has_vsa2);


    nit:

    --- a/arch/x86/kernel/geode_32.c
    +++ a/arch/x86/kernel/geode_32.c
    @@ -161,10 +161,10 @@ void geode_gpio_setup_event(unsigned int
    }
    EXPORT_SYMBOL_GPL(geode_gpio_setup_event);

    -static int has_vsa2 = -1;
    -
    int geode_has_vsa2(void)
    {
    + static int has_vsa2 = -1;
    +
    if (has_vsa2 == -1) {
    /*
    * The VSA has virtual registers that we can query for a

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] x86: GEODE: cache results from geode_has_vsa2() and uninline

    On Tue, 29 Apr 2008 13:35:12 -0700
    Andrew Morton wrote:

    > On Tue, 29 Apr 2008 01:32:13 -0400
    > Andres Salomon wrote:
    >
    > > On Mon, 28 Apr 2008 20:06:51 -0700
    > > Andrew Morton wrote:
    > >
    > > > On Mon, 21 Apr 2008 17:02:30 -0400 Andres Salomon wrote:
    > > >
    > > > > + if (!is_geode() || geode_has_vsa2())
    > > >
    > > > geode_has_vsa2() is a fairly expensive-looking function and afacit only
    > > > needs to be evaluated once per boot. Perhaps we should cache it somewhere?
    > > >

    > >
    > > How about this?
    > >

    >
    > Looks sane. Although one wonders if it should be cached as one of the
    > standard x86 feature bit thingies which show up in /proc/cpuinfo's 'flags'
    > field.
    >


    The VSA lives in a weird place between hardware and BIOS. I'm not
    really sure whether it's appropriate for it to be an x86_cap_flags (it
    hadn't occurred to me), but I think of it more as BIOS. Jordan, what do
    you think?



    > > +static int has_vsa2 = -1;
    > > +
    > > +int geode_has_vsa2(void)
    > > +{
    > > + if (has_vsa2 == -1) {
    > > + /*
    > > + * The VSA has virtual registers that we can query for a
    > > + * signature.
    > > + */
    > > + outw(VSA_VR_UNLOCK, VSA_VRC_INDEX);
    > > + outw(VSA_VR_SIGNATURE, VSA_VRC_INDEX);
    > > +
    > > + has_vsa2 = (inw(VSA_VRC_DATA) == VSA_SIG);
    > > + }
    > > +
    > > + return has_vsa2;
    > > +}
    > > +EXPORT_SYMBOL_GPL(geode_has_vsa2);

    >
    > nit:
    >
    > --- a/arch/x86/kernel/geode_32.c
    > +++ a/arch/x86/kernel/geode_32.c
    > @@ -161,10 +161,10 @@ void geode_gpio_setup_event(unsigned int
    > }
    > EXPORT_SYMBOL_GPL(geode_gpio_setup_event);
    >
    > -static int has_vsa2 = -1;
    > -
    > int geode_has_vsa2(void)
    > {
    > + static int has_vsa2 = -1;
    > +


    Looks good.

    Acked-by: Andres Salomon

    > if (has_vsa2 == -1) {
    > /*
    > * The VSA has virtual registers that we can query for a
    >



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)

    t Fri, 25 Apr 2008 18:51:04 +0200,
    I wrote:
    >
    > At Fri, 25 Apr 2008 20:45:51 +0400,
    > Stas Sergeev wrote:
    > >
    > > > But anyway, as mentioned in my previous post, snd-pcsp wouldn't be
    > > > enabled on most of distros' kernels because it cannot be built
    > > > together with input-pcspkr driver, unfortunately...

    > > Yes, making them to play well together is
    > > something to think about too. But I don't
    > > see how it can affect the distributors.
    > > If the distro doesn't have the sound enabled,
    > > then it won't enable snd-pcsp no matter
    > > what. If it does have the sound enabled,
    > > then why would it ever want to use pcspkr
    > > instead of snd-pcsp?

    >
    > The sound subsystem is enabled (loaded) only when necessary.
    > As long as there are many systems without the sound subsystem
    > (i.e. servers), snd-pcsp wouldn't be built (thus not provided even as
    > a module) for their kernels because it prevents input-pcspkr.


    .... and I completely missed the viewpoint of device allocation.
    Yeah, that'll be a bit hackish.


    Takashi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)

    Takashi Iwai wrote:
    >> The sound subsystem is enabled (loaded) only when necessary.
    >> As long as there are many systems without the sound subsystem
    >> (i.e. servers), snd-pcsp wouldn't be built (thus not provided even as
    >> a module) for their kernels because it prevents input-pcspkr.

    > ... and I completely missed the viewpoint of device allocation.
    > Yeah, that'll be a bit hackish.

    I'll appreciate if your replies
    became a bit less cryptic...
    What will be a bit hackish?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 6 of 6 FirstFirst ... 4 5 6