Hi Folks !
Is there any specific reason why you chose 1T (40 bit) as the location
of the 64-bit DMA window ?
It happens that most current radeon adapters cannot DMA there, they have
a 40-bit DMA limit. I seem to be getting things to work fine using a
39-bit window, but I suppose that might
Another question...
Do you guys happen to have a patch to emulate fsqrt in the kernel ?
Fedora 19 seems to be using it ... among others.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Another question...
Do you guys happen to have a patch to emulate fsqrt in the kernel ?
Fedora 19 seems to be using it ... among others.
You mean this one
arch/powerpc/math-emu/fsqrt.c ?
Yes.
Roy
On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
Another question...
Do you guys happen to have a patch to emulate fsqrt in the kernel ?
Seems this is already emulated:
arch/powerpc/math-emu/fsqrt.c
You can enable CONFIG_MATH_EMULATION to try.
Tiejun
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Hi Folks !
Is there any specific reason why you chose 1T (40 bit) as the location of
the 64-bit DMA window ?
It happens that most current radeon adapters cannot DMA there, they have
a 40-bit
On Fri, 2013-06-07 at 15:46 +0800, tiejun.chen wrote:
On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
Another question...
Do you guys happen to have a patch to emulate fsqrt in the kernel ?
Seems this is already emulated:
arch/powerpc/math-emu/fsqrt.c
You can enable
On Fri, 2013-06-07 at 07:45 +, Zang Roy-R61911 wrote:
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Another question...
Do you guys happen to have a patch to emulate fsqrt in the kernel ?
Fedora 19 seems to be using it ... among
On Fri, 2013-06-07 at 07:58 +, Zang Roy-R61911 wrote:
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Hi Folks !
Is there any specific reason why you chose 1T (40 bit) as the location of
the 64-bit DMA window ?
It happens that
On Fri, 2013-06-07 at 18:53 +1000, Benjamin Herrenschmidt wrote:
+
+static double crackpot_sqrt(double val)
+{
+int i;
+float x, y;
+const float f = 1.5F;
+
+x = val * 0.5F;
+y = val;
+i = * ( int * ) y;
+i = 0x5f3759df - ( i 1 );
+y = * ( float *
On 06/07/2013 04:53 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-07 at 15:46 +0800, tiejun.chen wrote:
On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
Another question...
Do you guys happen to have a patch to emulate fsqrt in the kernel ?
Seems this is already emulated:
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
On Fri, 2013-06-07 at 07:58 +, Zang Roy-R61911 wrote:
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Hi Folks !
Is there any specific
The MSR TM controls are in the top 32 bits of the MSR hence on 32 bit signals,
we stick the top half of the MSR in the checkpointed signal context so that the
user can access it.
Unfortunately, we don't currently write anything to the checkpointed signal
context when coming in a from a non
Currently sys_sigreturn() is TM unaware. Therefore, if we take a 32 bit signal
without SIGINFO (non RT) inside a transaction, on signal return we don't
restore the signal frame correctly.
This checks if the signal frame being restoring is an active transaction, and
if so, it copies the
Currently we clear out the MSR TM bits on signal return assuming that the
signal should never return to an active transaction.
This is bogus as the user may do this. It's most likely the transaction will
be doomed due to a treclaim but that's a problem for the HW not the kernel.
This removes
Currently we only restore signals which are transactionally suspended but it's
possible that the transaction can be restored even when it's active. Most
likely this will result in a transactional rollback by the hardware as the
transaction will have been doomed by an earlier treclaim.
The
Currently we only restore signals which are transactionally suspended but it's
possible that the transaction can be restored even when it's active. Most
likely this will result in a transactional rollback by the hardware as the
transaction will have been doomed by an earlier treclaim.
The
+
+static double crackpot_sqrt(double val)
+{
+int i;
+float x, y;
+const float f = 1.5F;
+
+x = val * 0.5F;
+y = val;
+i = * ( int * ) y;
+i = 0x5f3759df - ( i 1 );
+y = * ( float * ) i;
+y = y * ( f - ( x * y * y ) );
+y
On Friday, June 07, 2013 10:48:21 AM Viresh Kumar wrote:
On 31 May 2013 16:20, Viresh Kumar viresh.ku...@linaro.org wrote:
On 20 May 2013 10:10, Viresh Kumar viresh.ku...@linaro.org wrote:
On 13 May 2013 11:34, Viresh Kumar viresh.ku...@linaro.org wrote:
On 22 April 2013 12:19, Viresh Kumar
On Fri, 2013-06-07 at 17:02 +0800, tiejun.chen wrote:
On 06/07/2013 04:53 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-07 at 15:46 +0800, tiejun.chen wrote:
On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
Another question...
Do you guys happen to have a patch to emulate fsqrt
On Fri, 2013-06-07 at 09:44 +, Zang Roy-R61911 wrote:
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
On Fri, 2013-06-07 at 07:58 +, Zang Roy-R61911 wrote:
-Original Message-
From: Benjamin Herrenschmidt
Benjamin Herrenschmidt wrote:
PHY reset timed out
PHY reset timed out
PHY reset timed out
PHY reset timed out
This usually means that your RCW does not match your dip switch settings.
--
Timur Tabi
___
Linuxppc-dev mailing list
On Fri, 2013-06-07 at 11:48 +0100, David Laight wrote:
For those interested, this is the Quake3 sqrt from Carmack ...
there's
plenty of literature about it one or two google clicks away :-)
I guess that is a rough enough approximation for graphics.
However it will be miscompiled unless
On Jun 7, 2013, at 7:14 AM, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-07 at 11:48 +0100, David Laight wrote:
For those interested, this is the Quake3 sqrt from Carmack ...
there's
plenty of literature about it one or two google clicks away :-)
I guess that is a rough enough
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Date: Wed, 8 May 2013 22:59:29 -0700
Subject: [PATCH 1/2] perf/Power7: Save dcache_src fields in sample record.
Power7 saves the perf-event vector information in the mmcra register.
Included in this event vector is a data-cache source field
From 9f1a8a16e0ef36447e343d1cd4797c2b6a81225f Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Date: Fri, 7 Jun 2013 13:26:31 -0700
Subject: [PATCH 2/2] perf: Add support for the mem_xlvl field.
A follow-on patch to adding perf_mem_data_src support for Power7.
At this
On 06/07/2013 05:01:28 PM, Scott Wood wrote:
On 06/07/2013 07:09:20 AM, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-07 at 09:44 +, Zang Roy-R61911 wrote:
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
On Fri, 2013-06-07 at 07:58 +,
On Fri, 2013-06-07 at 17:02 -0500, Scott Wood wrote:
O
I thought the device tree was for describing the hardware, rather
than configuration? :-)
A bit of both really. See things like /chosen etc...
Also to what extent a MAC address is HW vs. configuration ? :-)
The HW configuration for a
On 06/07/2013 05:09:54 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-07 at 17:02 -0500, Scott Wood wrote:
O
I thought the device tree was for describing the hardware, rather
than configuration? :-)
A bit of both really. See things like /chosen etc...
Also to what extent a MAC address
On Fri, 2013-06-07 at 17:34 -0500, Scott Wood wrote:
You also need to account for other on-chip MMIOs no ? Or do you never
intend to let PCI devices hit them ?
I don't think we normally need that (other than MSIs, which have a
special window under 4G)... The question is whether it's
On Fri, 2013-06-07 at 14:19 -0500, Kumar Gala wrote:
I don't personally have the bandwidth to do a clean implementation (that
handles FP exceptions, NaNs, FPSCR, etc...) but I believe it would be
valuable if somebody else did (hint hint hint :-) since without this,
Fedora ppc64 is
On Sat, 2013-06-08 at 09:23 +1000, Benjamin Herrenschmidt wrote:
Ok, thinking out loud... looks like we might be able to just use existing
math-emu for that. From what I can tell, all it needs (other than enabling
the config option), is a call to flush_fp_to_thread(current);
While talking
On 06/07/2013 05:39:53 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-07 at 17:34 -0500, Scott Wood wrote:
You also need to account for other on-chip MMIOs no ? Or do you
never
intend to let PCI devices hit them ?
I don't think we normally need that (other than MSIs, which have a
On Sat, 2013-06-08 at 09:25 +1000, Benjamin Herrenschmidt wrote:
On Sat, 2013-06-08 at 09:23 +1000, Benjamin Herrenschmidt wrote:
Ok, thinking out loud... looks like we might be able to just use existing
math-emu for that. From what I can tell, all it needs (other than enabling
the config
On Fri, 2013-06-07 at 18:29 -0500, Scott Wood wrote:
I just meant that a PCIe device targeting something other than RAM,
CCSR (it's not just MSIs that are mapped through the special window),
or another PCIe is a rather unusual case -- not something that you'd
see by just plugging in an
On 06/06/2013 09:00:20 PM, Kevin Hao wrote:
As you can see, the only difference between these two logs is the
io resource address and all the mem and bus address are still the
same.
Hmm... The thing that originally motivated the picking of an arbitrary
primary was virtio being assigned a BAR
On Fri, 2013-06-07 at 17:20 -0700, Dan Malek wrote:
The purpose for that minimal code was the signal handlers were
hand-coded assembly that always did the FPU load/store regardless of
compiler flags. Over time, it became convenient to emulate a few
others, even with user space math
On Fri, 2013-06-07 at 18:13 -0700, Dan Malek wrote:
Hi Ben.
On Jun 7, 2013, at 5:34 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
The question is whether this is still relevant ?
The only answer I could provide is that it's dependent upon the
libraries and how the
37 matches
Mail list logo
