All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Porter <mporter@kernel.crashing.org>
To: John Whitney <johnw@sands-edge.com>
Cc: Matt Porter <mporter@kernel.crashing.org>,
	linuxppc-dev@lists.linuxppc.org
Subject: Re: Proposed changes to io.h
Date: Wed, 31 Mar 2004 15:07:41 -0700	[thread overview]
Message-ID: <20040331150741.D17284@home.com> (raw)
In-Reply-To: <9B139B02-834D-11D8-9FF0-000A95A07384@sands-edge.com>; from johnw@sands-edge.com on Wed, Mar 31, 2004 at 02:57:14PM -0500


On Wed, Mar 31, 2004 at 02:57:14PM -0500, John Whitney wrote:
> I don't see this in arch/ppc/Kconfig (or anywhere else) in the 2.6.5
> kernel which I am using (or in arch/ppc/config.in, for 2.4.25).  I can
> certainly create a patch to Kconfig that does this, or I could check
> for PPC_FEATURE_HAS_FPU in cur_cpu_spec[0]->cpu_user_features  in
> __raw_readq/writeq():
>
> unsigned long long __raw_readq (int addr)
> {
>    if (cur_cpu_spec[0]->cpu_user_features & PPC_FEATURE_HAS_FPU) {
>      ...
>    } else {
>      return *((volatile unsigned long long *) addr);
> }
>
> or somesuch.  This would work as long as the compiler doesn't have a
> snitfit with FP instructions, even if the processor can't use them...
>
> Which would the maintainers prefer?

Here's my preference, hopefully Paul reads this. I personally don't
see why we need to use a runtime flag when we pretty much have the
info available at build time anyway.  If e500 wanted a version they
can use the SPE option to add some code. It might be better to warn
at build time for !fpu in addition to BUGging at runtime.

-Matt

===== arch/ppc/Kconfig 1.56 vs edited =====
--- 1.56/arch/ppc/Kconfig	Thu Mar 18 23:04:54 2004
+++ edited/arch/ppc/Kconfig	Wed Mar 31 14:06:56 2004
@@ -79,6 +79,11 @@
 	depends on 44x
 	default y

+config PPC_FPU
+	bool
+	depends on 6xx || POWER3 || POWER4
+	default y
+
 config ALTIVEC
 	bool "AltiVec Support"
 	depends on 6xx || POWER4
===== include/asm-ppc/io.h 1.19 vs edited =====
--- 1.19/include/asm-ppc/io.h	Fri Mar 12 14:17:57 2004
+++ edited/include/asm-ppc/io.h	Wed Mar 31 14:57:41 2004
@@ -69,6 +69,77 @@
 #define __raw_writew(v, addr)	(*(volatile unsigned short *)(addr) = (v))
 #define __raw_writel(v, addr)	(*(volatile unsigned int *)(addr) = (v))

+#ifdef CONFIG_PPC_FPU
+/*
+ * For reading and writing 64-bit values, we need to use the floating
+ * point registers.  The code will enable MSR_FP in the MSR register,
+ * use FPR1 to read from and write to memory, and then restore
+ * everything to the previous values.
+ */
+static inline unsigned long long ___raw_readq(int addr)
+{
+	unsigned long flags;
+	unsigned long msr;
+	unsigned long msr_save;
+	unsigned long long result;
+	unsigned long long fp_save;
+
+	local_irq_save (flags);
+	asm volatile ("sync\n"
+			"mfmsr    %0\n"
+			"ori      %1,%0,0x2000\n"
+			"mtmsr    %1\n"
+			"isync\n"
+			"stfdx    1,0,%2\n"
+			"lfdx     1,0,%4\n"
+			"stfdx    1,0,%3\n"
+			"sync\n"
+			"lfdx     1,0,%2\n"
+			"mtmsr    %0\n"
+			"sync\n"
+			"isync\n"
+			: "=&r" (msr_save), "=&r" (msr)
+			: "r" (&fp_save), "r" (&result), "r" (addr)
+			: "memory" );
+	local_irq_restore (flags);
+
+	return result;
+}
+
+static inline void ___raw_writeq(unsigned long long value, int addr)
+{
+	unsigned long flags;
+	unsigned long msr;
+	unsigned long msr_save;
+	unsigned long long fp_save;
+
+	local_irq_save (flags);
+	asm volatile ("sync\n"
+			"mfmsr    %0\n"
+			"ori      %1,%0,0x2000\n"
+			"mtmsr    %1\n"
+			"isync\n"
+			"stfdx    1,0,%2\n"
+			"lfdx     1,0,%3\n"
+			"stfdx    1,0,%4\n"
+			"sync\n"
+			"lfdx     1,0,%2\n"
+			"mtmsr    %0\n"
+			"sync\n"
+			"isync\n"
+			: "=&r" (msr_save), "=&r" (msr)
+			: "r" (&fp_save), "r" (&value), "r" (addr)
+			: "memory" );
+	local_irq_restore (flags);
+	return;
+}
+#define __raw_readq		___raw_readq
+#define __raw_writeq		___raw_writeq
+#else /* !CONFIG_PPC_FPU */
+#define __raw_readq(addr)		({ BUG(); })
+#define __raw_writeq(addr)		({ BUG(); })
+#endif /* CONFIG_PPC_FPU */
+
 /*
  * The insw/outsw/insl/outsl macros don't do byte-swapping.
  * They are only used in practice for transferring buffers which

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2004-03-31 22:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-31 15:44 Proposed changes to io.h John Whitney
2004-03-31 16:44 ` Eugene Surovegin
2004-03-31 16:58   ` Dan Malek
2004-03-31 17:30     ` Matt Porter
2004-03-31 17:32     ` John Whitney
2004-03-31 17:40       ` Dan Malek
2004-03-31 17:03   ` Matt Porter
2004-03-31 19:57     ` John Whitney
2004-03-31 22:07       ` Matt Porter [this message]
2004-03-31 22:25         ` John Whitney
2004-03-31 22:52         ` Dan Malek
2004-04-01  5:30           ` Kumar Gala
2004-03-31 17:01 ` Matt Porter
2004-03-31 17:29   ` Dan Malek
2004-03-31 18:18 ` Christoph Hellwig
2004-03-31 18:40   ` John Whitney
2004-03-31 18:43     ` Christoph Hellwig
2004-03-31 18:50       ` John Whitney
2004-03-31 21:09   ` John Whitney
2004-03-31 21:49     ` Dan Malek
2004-03-31 21:52     ` Eugene Surovegin
2004-03-31 22:07       ` John Whitney
2004-04-01  2:52 ` Benjamin Herrenschmidt
     [not found]   ` <209F76E4-838B-11D8-9FF0-000A95A07384@sands-edge.com>
     [not found]     ` <1080790433.1433.59.camel@gaston>
     [not found]       ` <43B0E668-84BC-11D8-9FF0-000A95A07384@sands-edge.com>
2004-04-03  3:04         ` Benjamin Herrenschmidt
2004-04-03  3:40           ` John Whitney

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=20040331150741.D17284@home.com \
    --to=mporter@kernel.crashing.org \
    --cc=johnw@sands-edge.com \
    --cc=linuxppc-dev@lists.linuxppc.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.