From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jimi Xenidis <jimix@pobox.com>
Cc: Michael Neuling <mikey@neuling.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: Hijacking CPU_FTR_VSX for BGQ QPX
Date: Sat, 10 Nov 2012 06:57:09 +1100 [thread overview]
Message-ID: <1352491029.23412.3.camel@pasglop> (raw)
In-Reply-To: <29970ED2-02E3-45F5-96FD-B4270385E3ED@pobox.com>
On Fri, 2012-11-09 at 11:43 -0600, Jimi Xenidis wrote:
> The CPU_FTR_* values are pretty tight (a few bits left) yes I need to save and restore the QPX registers.
> There are 32 QPX registers, each 32 bytes in size, it is otherwise managed by the FPSCR and MSR[FP]
>
> I was thinking that I could hijack the VSX, since there is no plan to add it to embedded yet.
> I could be explicit or create an alieas fo the same bit, but the basic effect (after increasing the save area size) would be something like the diff below.
> Thoughts?
Don't. Use a different bit, we can always split the mask again if
needed, move more bits to mmu_features etc...
> -#ifdef CONFIG_VSX
> +#if defined (CONFIG_VSX) && defined(CONFIG_BGQ)
> +# error "This code depends on CONFIG_VSX and CONFIG_BGQ being exclusive
> +#elif defined (CONFIG_VSX)
> +# define _REST_32VSRS(n,c,base) REST_32VSRS(n,c,base)
> +# define _SAVE_32VSRS(n,c,base) SAVE_32VSRS(n,c,base)
> +#elif defined(CONFIG_BGQ)
Make a CONFIG_PPC_QPX or something like that specifically for the QPX
stuff that you can then "select" from CONFIG_PPC_BGQ (don't do just
CONFIG_BGQ).
And don't just "hijack" stuff like that, it should be a runtime option,
so add a new set etc... it should be possible to build a kernel that
boots on a BGQ or a hypothetical BookE chip with VSX.
> +# define _REST_32VSRS(n,c,base) REST_32QRS(n,c,base)
> +# define _SAVE_32VSRS(n,c,base) SAVE_32QRS(n,c,base)
> +#endif
> +
> +#if defined (CONFIG_VSX) || defined(CONFIG_BGQ)
> #define REST_32FPVSRS(n,c,base) \
> BEGIN_FTR_SECTION \
> b 2f; \
> END_FTR_SECTION_IFSET(CPU_FTR_VSX); \
> REST_32FPRS(n,base); \
> b 3f; \
> -2: REST_32VSRS(n,c,base); \
> +2: _REST_32VSRS(n,c,base); \
> 3:
>
> #define SAVE_32FPVSRS(n,c,base) \
> @@ -41,7 +51,7 @@ BEGIN_FTR_SECTION \
> END_FTR_SECTION_IFSET(CPU_FTR_VSX); \
> SAVE_32FPRS(n,base); \
> b 3f; \
> -2: SAVE_32VSRS(n,c,base); \
> +2: _SAVE_32VSRS(n,c,base); \
> 3:
> #else
> #define REST_32FPVSRS(n,b,base) REST_32FPRS(n, base)
Cheers,
Ben.
next prev parent reply other threads:[~2012-11-09 19:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-09 17:43 Hijacking CPU_FTR_VSX for BGQ QPX Jimi Xenidis
2012-11-09 19:57 ` Benjamin Herrenschmidt [this message]
2012-11-10 4:33 ` Michael Neuling
2012-12-05 15:44 ` Jimi Xenidis
2012-12-06 2:00 ` Michael Neuling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1352491029.23412.3.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=jimix@pobox.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mikey@neuling.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.