* Re: SATA FSL and upstreaming
From: Benjamin Herrenschmidt @ 2013-06-07 4:39 UTC (permalink / raw)
To: Timur Tabi
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Zang Roy-R61911,
tiejun.chen, Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1370577138.3766.342.camel@pasglop>
On Fri, 2013-06-07 at 13:52 +1000, Benjamin Herrenschmidt wrote:
> So I got the rev2 chip today, put it in, and PCI-E is still not getting
> a link. Since the LEDs of the e1000 aren't coming up at all, I *suspect*
> the slots are getting no power.
>
> Is there a power control somewhere ? Maybe some DIP or jumpers that
> might have gone off ?
Forget it, reset all the jumpers to the default setup (found the doc !)
and they come up now in slot 4 and 7. It also looks like uBoot now
has an e1000 driver so I don't have to use fman (for which I believe
there is still no upstream driver right ?)
BTW. Is that normal during boot ?
Net: Initializing Fman
Fman1: Uploading microcode version 106.1.7
PHY reset timed out
PHY reset timed out
PHY reset timed out
PHY reset timed out
Cheers,
Ben.
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Zang Roy-R61911 @ 2013-06-07 4:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Timur Tabi
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1370579976.3766.345.camel@pasglop>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Benjamin
> Herrenschmidt
> Sent: Friday, June 07, 2013 12:40 PM
> To: Timur Tabi
> Cc: Xie Shaohui-B21989; Liu Qiang-B32616; Zang Roy-R61911; tiejun.chen;
> Fleming Andy-AFLEMING; Bhushan Bharat-R65777; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: SATA FSL and upstreaming
>=20
> On Fri, 2013-06-07 at 13:52 +1000, Benjamin Herrenschmidt wrote:
>=20
> > So I got the rev2 chip today, put it in, and PCI-E is still not
> > getting a link. Since the LEDs of the e1000 aren't coming up at all, I
> > *suspect* the slots are getting no power.
> >
> > Is there a power control somewhere ? Maybe some DIP or jumpers that
> > might have gone off ?
>=20
> Forget it, reset all the jumpers to the default setup (found the doc !)
> and they come up now in slot 4 and 7. It also looks like uBoot now has an
> e1000 driver so I don't have to use fman (for which I believe there is
> still no upstream driver right ?)
fman in u-boot has been up streamed. It should work.
>=20
> BTW. Is that normal during boot ?
>=20
> Net: Initializing Fman
> Fman1: Uploading microcode version 106.1.7 PHY reset timed out PHY reset
> timed out PHY reset timed out PHY reset timed out
You can ignore the timeout.=20
Do you plug other card (for example SGMII card) on the board?
u-boot detects some card in the slot and tries to init the PHY but fails.
Roy
^ permalink raw reply
* Re: SATA FSL and upstreaming
From: Benjamin Herrenschmidt @ 2013-06-07 4:47 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B2135A0@039-SN2MPN1-012.039d.mgd.msft.net>
On Fri, 2013-06-07 at 04:45 +0000, Zang Roy-R61911 wrote:
>
> > Forget it, reset all the jumpers to the default setup (found the doc !)
> > and they come up now in slot 4 and 7. It also looks like uBoot now has an
> > e1000 driver so I don't have to use fman (for which I believe there is
> > still no upstream driver right ?)
> fman in u-boot has been up streamed. It should work.
I don't care much about u-boot :-) It's the kernel that matters to me.
> >
> > BTW. Is that normal during boot ?
> >
> > Net: Initializing Fman
> > Fman1: Uploading microcode version 106.1.7 PHY reset timed out PHY reset
> > timed out PHY reset timed out PHY reset timed out
> You can ignore the timeout.
> Do you plug other card (for example SGMII card) on the board?
No, only PCIe in slot 4 and 7.
> u-boot detects some card in the slot and tries to init the PHY but fails.
Cheers,
Ben.
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Zang Roy-R61911 @ 2013-06-07 4:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1370580426.3766.349.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogRnJpZGF5
LCBKdW5lIDA3LCAyMDEzIDEyOjQ3IFBNDQo+IFRvOiBaYW5nIFJveS1SNjE5MTENCj4gQ2M6IFRp
bXVyIFRhYmk7IFhpZSBTaGFvaHVpLUIyMTk4OTsgTGl1IFFpYW5nLUIzMjYxNjsgdGllanVuLmNo
ZW47DQo+IEZsZW1pbmcgQW5keS1BRkxFTUlORzsgQmh1c2hhbiBCaGFyYXQtUjY1Nzc3OyBsaW51
eHBwYy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFNBVEEgRlNMIGFu
ZCB1cHN0cmVhbWluZw0KPiANCj4gT24gRnJpLCAyMDEzLTA2LTA3IGF0IDA0OjQ1ICswMDAwLCBa
YW5nIFJveS1SNjE5MTEgd3JvdGU6DQo+ID4NCj4gPiA+IEZvcmdldCBpdCwgcmVzZXQgYWxsIHRo
ZSBqdW1wZXJzIHRvIHRoZSBkZWZhdWx0IHNldHVwIChmb3VuZCB0aGUgZG9jDQo+ID4gPiAhKSBh
bmQgdGhleSBjb21lIHVwIG5vdyBpbiBzbG90IDQgYW5kIDcuIEl0IGFsc28gbG9va3MgbGlrZSB1
Qm9vdA0KPiA+ID4gbm93IGhhcyBhbiBlMTAwMCBkcml2ZXIgc28gSSBkb24ndCBoYXZlIHRvIHVz
ZSBmbWFuIChmb3Igd2hpY2ggSQ0KPiA+ID4gYmVsaWV2ZSB0aGVyZSBpcyBzdGlsbCBubyB1cHN0
cmVhbSBkcml2ZXIgcmlnaHQgPykNCj4gDQo+ID4gZm1hbiBpbiB1LWJvb3QgaGFzIGJlZW4gdXAg
c3RyZWFtZWQuICBJdCBzaG91bGQgd29yay4NCj4gDQo+IEkgZG9uJ3QgY2FyZSBtdWNoIGFib3V0
IHUtYm9vdCA6LSkgSXQncyB0aGUga2VybmVsIHRoYXQgbWF0dGVycyB0byBtZS4NCllvdSBzaG91
bGQgbWF0dGVyIGEgd29ya2luZyBFdGhlcm5ldCBwb3J0IDotKSBpbiB1LWJvb3QuDQoNCj4gDQo+
ID4gPg0KPiA+ID4gQlRXLiBJcyB0aGF0IG5vcm1hbCBkdXJpbmcgYm9vdCA/DQo+ID4gPg0KPiA+
ID4gTmV0OiAgIEluaXRpYWxpemluZyBGbWFuDQo+ID4gPiBGbWFuMTogVXBsb2FkaW5nIG1pY3Jv
Y29kZSB2ZXJzaW9uIDEwNi4xLjcgUEhZIHJlc2V0IHRpbWVkIG91dCBQSFkNCj4gPiA+IHJlc2V0
IHRpbWVkIG91dCBQSFkgcmVzZXQgdGltZWQgb3V0IFBIWSByZXNldCB0aW1lZCBvdXQNCj4gPiBZ
b3UgY2FuIGlnbm9yZSB0aGUgdGltZW91dC4NCj4gPiBEbyB5b3UgcGx1ZyBvdGhlciBjYXJkIChm
b3IgZXhhbXBsZSBTR01JSSBjYXJkKSBvbiB0aGUgYm9hcmQ/DQo+IA0KPiBObywgb25seSBQQ0ll
IGluIHNsb3QgNCBhbmQgNy4NCkdvIGFoZWFkIC4uLg0KVW5sZXNzIHRoZXJlIGlzIGEgY29tcGxl
dGUgdS1ib290IGxvZywgSSBjYW4gY29tbWVudCBtb3JlLiBidXQgSSBkbyBub3QgdGhpbmsgaXQg
aXMgdGhlIGZvY3VzIG5vdyAuLi4NCnRoYW5rcy4NClJveQ0K
^ permalink raw reply
* Re: [PATCH 17/18] cpufreq: powerpc: move cpufreq driver to drivers/cpufreq
From: Viresh Kumar @ 2013-06-07 5:18 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: deepthi, Robin Randhawa, linux-pm, patches, Liviu.Dudau,
linux-kernel, cpufreq, Steve.Bannister, Paul Mackerras,
Olof Johansson, Andrew Morton, arvind.chauhan, linuxppc-dev,
linaro-kernel, charles.garcia-tobin
In-Reply-To: <CAKohpokgTmb6d79ipR9pV2iOfLSzngrPbMV3hFcuP64kbNYSQA@mail.gmail.com>
On 31 May 2013 16:20, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 20 May 2013 10:10, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> On 13 May 2013 11:34, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>> On 22 April 2013 12:19, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>>> On 9 April 2013 14:05, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>>>> On 5 April 2013 12:16, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>>>>> On 4 April 2013 18:24, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>>>>>> This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
>>>>>>>
>>>>>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>>>>> Cc: Paul Mackerras <paulus@samba.org>
>>>>>>> Cc: Olof Johansson <olof@lixom.net>
>>>>>>> Cc: linuxppc-dev@lists.ozlabs.org
>>>>>>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>>>>>>> ---
>>>>>>> Compile Tested only.
>>>>>>>
>>>>>>> arch/powerpc/platforms/Kconfig | 31 ----------------------
>>>>>>> arch/powerpc/platforms/pasemi/Makefile | 1 -
>>>>>>> arch/powerpc/platforms/powermac/Makefile | 2 --
>>>>>>> drivers/cpufreq/Kconfig.powerpc | 26 ++++++++++++++++++
>>>>>>> drivers/cpufreq/Makefile | 3 +++
>>>>>>> .../cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c | 0
>>>>>>> .../cpufreq/pmac32-cpufreq.c | 0
>>>>>>> .../cpufreq/pmac64-cpufreq.c | 0
>>>>>>> 8 files changed, 29 insertions(+), 34 deletions(-)
>>>>>>> rename arch/powerpc/platforms/pasemi/cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c (100%)
>>>>>>> rename arch/powerpc/platforms/powermac/cpufreq_32.c => drivers/cpufreq/pmac32-cpufreq.c (100%)
>>>>>>> rename arch/powerpc/platforms/powermac/cpufreq_64.c => drivers/cpufreq/pmac64-cpufreq.c (100%)
>>>>>>
>>>>>> Hi Deepthi,
>>>>>>
>>>>>> Can you help testing this please?
>>>>>
>>>>> Ping!!
>>>>
>>>> Ping!!
>>>
>>> Hi Benjamin,
>>>
>>> Hope you are back from your vacations. Can you give it a try now?
>>
>> Ping!!
>
> Ping!!
Hi Rafael,
Its been more than 2 months now that this patch was first posted.
And the response from Maintainers isn't so great, irrespective of
how many times I pinged them.
This is what I think:
- It looked functionally correct to Benjamin but he wanted somebody
to actually test it.
- Arnd gave his Ack (So it looked functionally correct to him too)
- We can probably push this into linux-next now and see if somebody
complains of any breakage it has done. If not we can get it pushed for
3.11.
--
viresh
^ permalink raw reply
* [PATCH] powerpc: Print instruction when logging unhandled exceptions
From: Anton Blanchard @ 2013-06-07 5:42 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
It is often useful to see the instruction that caused an unhandled
exception.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
We print all ones if the get_user fails, do we want to go to
the added effort of printing XXXXXXXX like we do in the oops
code?
Index: b/arch/powerpc/kernel/traps.c
===================================================================
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -242,9 +242,9 @@ void _exception(int signr, struct pt_reg
{
siginfo_t info;
const char fmt32[] = KERN_INFO "%s[%d]: unhandled signal %d " \
- "at %08lx nip %08lx lr %08lx code %x\n";
+ "at %08lx nip %08lx lr %08lx code %x insn %08x\n";
const char fmt64[] = KERN_INFO "%s[%d]: unhandled signal %d " \
- "at %016lx nip %016lx lr %016lx code %x\n";
+ "at %016lx nip %016lx lr %016lx code %x insn %08x\n";
if (!user_mode(regs)) {
die("Exception in kernel mode", regs, signr);
@@ -252,9 +252,14 @@ void _exception(int signr, struct pt_reg
}
if (show_unhandled_signals && unhandled_signal(current, signr)) {
+ u32 insn;
+
+ if (get_user(insn, (u32 __user *)(regs->nip)))
+ insn = 0xffffffff;
+
printk_ratelimited(regs->msr & MSR_64BIT ? fmt64 : fmt32,
current->comm, current->pid, signr,
- addr, regs->nip, regs->link, code);
+ addr, regs->nip, regs->link, code, insn);
}
if (arch_irqs_disabled() && !arch_irq_disabled_regs(regs))
^ permalink raw reply
* FSL 64-bit DMA window question
From: Benjamin Herrenschmidt @ 2013-06-07 7:05 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B2135A0@039-SN2MPN1-012.039d.mgd.msft.net>
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 collide with something else ?
Can you guys consider changing the default ?
Cheers,
Ben.
^ permalink raw reply
* fsqrt
From: Benjamin Herrenschmidt @ 2013-06-07 7:41 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B213817@039-SN2MPN1-012.039d.mgd.msft.net>
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.
^ permalink raw reply
* RE: fsqrt
From: Zang Roy-R61911 @ 2013-06-07 7:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1370590884.3766.357.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gQW5vdGhlciBxdWVz
dGlvbi4uLg0KPiANCj4gRG8geW91IGd1eXMgaGFwcGVuIHRvIGhhdmUgYSBwYXRjaCB0byBlbXVs
YXRlIGZzcXJ0IGluIHRoZSBrZXJuZWwgPw0KPiANCj4gRmVkb3JhIDE5IHNlZW1zIHRvIGJlIHVz
aW5nIGl0IC4uLiBhbW9uZyBvdGhlcnMuDQpZb3UgbWVhbiB0aGlzIG9uZQ0KYXJjaC9wb3dlcnBj
L21hdGgtZW11L2ZzcXJ0LmMgPw0KWWVzLg0KUm95DQo=
^ permalink raw reply
* Re: fsqrt
From: tiejun.chen @ 2013-06-07 7:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Zang Roy-R61911, Timur Tabi,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1370590884.3766.357.camel@pasglop>
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
^ permalink raw reply
* RE: FSL 64-bit DMA window question
From: Zang Roy-R61911 @ 2013-06-07 7:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1370588727.3766.355.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gDQo+IEhpIEZvbGtz
ICENCj4gDQo+IElzIHRoZXJlIGFueSBzcGVjaWZpYyByZWFzb24gd2h5IHlvdSBjaG9zZSAxVCAo
NDAgYml0KSBhcyB0aGUgbG9jYXRpb24gb2YNCj4gdGhlIDY0LWJpdCBETUEgd2luZG93ID8NCj4g
DQo+IEl0IGhhcHBlbnMgdGhhdCBtb3N0IGN1cnJlbnQgcmFkZW9uIGFkYXB0ZXJzIGNhbm5vdCBE
TUEgdGhlcmUsIHRoZXkgaGF2ZQ0KPiBhIDQwLWJpdCBETUEgbGltaXQuIEkgc2VlbSB0byBiZSBn
ZXR0aW5nIHRoaW5ncyB0byB3b3JrIGZpbmUgdXNpbmcgYSAzOS0NCj4gYml0IHdpbmRvdywgYnV0
IEkgc3VwcG9zZSB0aGF0IG1pZ2h0IGNvbGxpZGUgd2l0aCBzb21ldGhpbmcgZWxzZSA/DQpUNDI0
MCBoYXMgNDBiaXQgcGh5c2ljYWwgYWRkcmVzcyBhYmlsaXR5Lg0KIg0KVGhpcyBjaGlwJ3MgNDAt
Yml0LCBwaHlzaWNhbCBhZGRyZXNzIG1hcCBjb25zaXN0cyBvZiBsb2NhbCBzcGFjZSBhbmQgZXh0
ZXJuYWwgYWRkcmVzcw0Kc3BhY2UuIEZvciB0aGUgbG9jYWwgYWRkcmVzcyBtYXAsIDMyIGxvY2Fs
IGFjY2VzcyB3aW5kb3dzIChMQVdzKSBkZWZpbmUgbWFwcGluZw0Kd2l0aGluIHRoZSBsb2NhbCA0
MC1iaXQgKDEgVEIpIGFkZHJlc3Mgc3BhY2UuIEluYm91bmQgYW5kIG91dGJvdW5kIHRyYW5zbGF0
aW9uIHdpbmRvd3MNCmNhbiBtYXAgdGhlIGNoaXAgaW50byBhIGxhcmdlciBzeXN0ZW0gYWRkcmVz
cyBzcGFjZSBzdWNoIGFzIHRoZSBSYXBpZElPIG9yIFBDSWUgNjQtYml0DQphZGRyZXNzIGVudmly
b25tZW50LiBUaGlzIGZ1bmN0aW9uYWxpdHkgaXMgaW5jbHVkZWQgaW4gdGhlIGFkZHJlc3MgdHJh
bnNsYXRpb24gYW5kDQptYXBwaW5nIHVuaXRzIChBVE1VcykuDQoNCiINClRoYXQgc2hvdWxkIGJl
IHRoZSByZWFzb24gdG8gc2V0IHRoZSBETUEgd2luZG93IHRvIDQwLWJpdC4NCg0KPiANCj4gQ2Fu
IHlvdSBndXlzIGNvbnNpZGVyIGNoYW5naW5nIHRoZSBkZWZhdWx0ID8NCkFueSBjb2xsaWRlIGZv
ciA0MGJpdD8NClJveQ0K
^ permalink raw reply
* Re: fsqrt
From: Benjamin Herrenschmidt @ 2013-06-07 8:53 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B213A62@039-SN2MPN1-012.039d.mgd.msft.net>
On Fri, 2013-06-07 at 07:45 +0000, Zang Roy-R61911 wrote:
>
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@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 ?
No. This is for setups that have no FPU, I don't think that will work
with an actual FPU.
fsqrt is an optional instruction in the architecture and FSL chips don't
use it. However it looks like Fedora is compiled with a toolchain that
generates it.
I've successfully launched the Fedora installer using this hack in the
kernel:
>From f75adba1ee91691d431e283184e15412114000d1 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 7 Jun 2013 18:42:44 +1000
Subject: [PATCH] Gross hack
---
arch/powerpc/include/asm/ppc-opcode.h | 2 ++
arch/powerpc/kernel/Makefile | 4 ++-
arch/powerpc/kernel/fsqrt-emu.c | 44 +++++++++++++++++++++++++++++++++
arch/powerpc/kernel/traps.c | 7 ++++++
4 files changed, 56 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/kernel/fsqrt-emu.c
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index eccfc16..146c5e9 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -88,6 +88,8 @@
#define PPC_INST_DCBA_MASK 0xfc0007fe
#define PPC_INST_DCBAL 0x7c2005ec
#define PPC_INST_DCBZL 0x7c2007ec
+#define PPC_INST_FSQRT 0xfc00002c
+#define PPC_INST_FSQRT_MASK 0xfc1f07fe
#define PPC_INST_ICBT 0x7c00002c
#define PPC_INST_ISEL 0x7c00001e
#define PPC_INST_ISEL_MASK 0xfc00003e
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index f960a79..64c9962 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -26,6 +26,8 @@ CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog
CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog
endif
+CFLAGS_REMOVE_fsqrt-emu.o = -msoft-float
+
obj-y := cputable.o ptrace.o syscalls.o \
irq.o align.o signal_32.o pmc.o vdso.o \
process.o systbl.o idle.o \
@@ -34,7 +36,7 @@ obj-y := cputable.o ptrace.o syscalls.o \
udbg.o misc.o io.o dma.o \
misc_$(CONFIG_WORD_SIZE).o vdso32/
obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
- signal_64.o ptrace32.o \
+ signal_64.o ptrace32.o fsqrt-emu.o \
paca.o nvram_64.o firmware.o
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_ppc970.o cpu_setup_pa6t.o
diff --git a/arch/powerpc/kernel/fsqrt-emu.c b/arch/powerpc/kernel/fsqrt-emu.c
new file mode 100644
index 0000000..2da4f71
--- /dev/null
+++ b/arch/powerpc/kernel/fsqrt-emu.c
@@ -0,0 +1,44 @@
+#include <linux/kernel.h>
+#include <linux/preempt.h>
+#include <linux/sched.h>
+#include <asm/ptrace.h>
+#include <asm/processor.h>
+#include <asm/switch_to.h>
+
+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 = y * ( f - ( x * y * y ) );
+ return val * y;
+}
+
+int emulate_fsqrt_inst(struct pt_regs *regs, u32 instword)
+{
+ unsigned int frt_r = (instword >> 21) & 0x1f;
+ unsigned int frb_r = (instword >> 21) & 0x1f;
+ double frt, frb;
+
+ /* XXX THIS WHOLE THING IS JUST A HACK ! */
+ preempt_disable();
+ enable_kernel_fp();
+ frb = current->thread.fpr[frb_r][0];
+ frt = crackpot_sqrt(frb);
+ current->thread.fpr[frt_r][0] = frt;
+ if (instword & 1)
+ regs->ccr &= 0xff00ffff;
+ preempt_enable();
+
+ return 0;
+}
+
+
+
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 6dfbb38..e677792 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -938,6 +938,8 @@ static int emulate_isel(struct pt_regs *regs, u32 instword)
return 0;
}
+extern int emulate_fsqrt_inst(struct pt_regs *regs, u32 instword);
+
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
static inline bool tm_abort_check(struct pt_regs *regs, int cause)
{
@@ -1018,6 +1020,11 @@ static int emulate_instruction(struct pt_regs *regs)
return emulate_isel(regs, instword);
}
+ if ((instword & PPC_INST_FSQRT_MASK) == PPC_INST_FSQRT) {
+ PPC_WARN_EMULATED(isel, regs);
+ return emulate_fsqrt_inst(regs, instword);
+ }
+
#ifdef CONFIG_PPC64
/* Emulate the mfspr rD, DSCR. */
if ((((instword & PPC_INST_MFSPR_DSCR_USER_MASK) ==
--
1.7.10.4
^ permalink raw reply related
* Re: fsqrt
From: Benjamin Herrenschmidt @ 2013-06-07 8:53 UTC (permalink / raw)
To: tiejun.chen
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Zang Roy-R61911, Timur Tabi,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <51B18FD0.5040909@windriver.com>
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 CONFIG_MATH_EMULATION to try.
Is math emu expected to work at all on top of a real FPU ? I though it
didn't ... maybe I'm wrong.
Cheers,
Ben.
^ permalink raw reply
* Re: FSL 64-bit DMA window question
From: Benjamin Herrenschmidt @ 2013-06-07 8:55 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B213AA9@039-SN2MPN1-012.039d.mgd.msft.net>
On Fri, 2013-06-07 at 07:58 +0000, Zang Roy-R61911 wrote:
>
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@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 DMA limit. I seem to be getting things to work fine using a 39-
> > bit window, but I suppose that might collide with something else ?
> T4240 has 40bit physical address ability.
> "
> This chip's 40-bit, physical address map consists of local space and external address
> space. For the local address map, 32 local access windows (LAWs) define mapping
> within the local 40-bit (1 TB) address space. Inbound and outbound translation windows
> can map the chip into a larger system address space such as the RapidIO or PCIe 64-bit
> address environment. This functionality is included in the address translation and
> mapping units (ATMUs).
>
> "
> That should be the reason to set the DMA window to 40-bit.
I see. However if the top half of that space isn't used by default with
whatever is our current setup, it makes sense to move down the 64-bit
DMA window to allow those adapters to function don't you think ?
I'm trying to turn those FSL boxes into nice ppc64 dev. workstations :-)
Cheers,
Ben.
> >
> > Can you guys consider changing the default ?
> Any collide for 40bit?
> Roy
^ permalink raw reply
* Re: fsqrt
From: Benjamin Herrenschmidt @ 2013-06-07 8:59 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1370595190.3766.359.camel@pasglop>
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 * ) &i;
> + y = y * ( f - ( x * y * y ) );
> + y = y * ( f - ( x * y * y ) );
> + return val * y;
> +}
> +
For those interested, this is the Quake3 sqrt from Carmack ... there's
plenty of literature about it one or two google clicks away :-)
Cheers,
Ben.
^ permalink raw reply
* Re: fsqrt
From: tiejun.chen @ 2013-06-07 9:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Zang Roy-R61911, Timur Tabi,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1370595233.3766.360.camel@pasglop>
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:
>>
>> arch/powerpc/math-emu/fsqrt.c
>>
>> You can enable CONFIG_MATH_EMULATION to try.
>
> Is math emu expected to work at all on top of a real FPU ? I though it
> didn't ... maybe I'm wrong.
As I understand often the real FPU can't support all float instructions, so we
have to enable this to emulate those unsupported float instructions in that
scenario.
Tiejun
^ permalink raw reply
* RE: FSL 64-bit DMA window question
From: Zang Roy-R61911 @ 2013-06-07 9:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1370595309.3766.361.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gDQo+IE9uIEZyaSwg
MjAxMy0wNi0wNyBhdCAwNzo1OCArMDAwMCwgWmFuZyBSb3ktUjYxOTExIHdyb3RlOg0KPiA+DQo+
ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogQmVuamFtaW4gSGVy
cmVuc2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gPiA+DQo+ID4g
PiBIaSBGb2xrcyAhDQo+ID4gPg0KPiA+ID4gSXMgdGhlcmUgYW55IHNwZWNpZmljIHJlYXNvbiB3
aHkgeW91IGNob3NlIDFUICg0MCBiaXQpIGFzIHRoZQ0KPiBsb2NhdGlvbiBvZg0KPiA+ID4gdGhl
IDY0LWJpdCBETUEgd2luZG93ID8NCj4gPiA+DQo+ID4gPiBJdCBoYXBwZW5zIHRoYXQgbW9zdCBj
dXJyZW50IHJhZGVvbiBhZGFwdGVycyBjYW5ub3QgRE1BIHRoZXJlLCB0aGV5DQo+IGhhdmUNCj4g
PiA+IGEgNDAtYml0IERNQSBsaW1pdC4gSSBzZWVtIHRvIGJlIGdldHRpbmcgdGhpbmdzIHRvIHdv
cmsgZmluZSB1c2luZyBhDQo+IDM5LQ0KPiA+ID4gYml0IHdpbmRvdywgYnV0IEkgc3VwcG9zZSB0
aGF0IG1pZ2h0IGNvbGxpZGUgd2l0aCBzb21ldGhpbmcgZWxzZSA/DQo+ID4gVDQyNDAgaGFzIDQw
Yml0IHBoeXNpY2FsIGFkZHJlc3MgYWJpbGl0eS4NCj4gPiAiDQo+ID4gVGhpcyBjaGlwJ3MgNDAt
Yml0LCBwaHlzaWNhbCBhZGRyZXNzIG1hcCBjb25zaXN0cyBvZiBsb2NhbCBzcGFjZSBhbmQNCj4g
ZXh0ZXJuYWwgYWRkcmVzcw0KPiA+IHNwYWNlLiBGb3IgdGhlIGxvY2FsIGFkZHJlc3MgbWFwLCAz
MiBsb2NhbCBhY2Nlc3Mgd2luZG93cyAoTEFXcykgZGVmaW5lDQo+IG1hcHBpbmcNCj4gPiB3aXRo
aW4gdGhlIGxvY2FsIDQwLWJpdCAoMSBUQikgYWRkcmVzcyBzcGFjZS4gSW5ib3VuZCBhbmQgb3V0
Ym91bmQNCj4gdHJhbnNsYXRpb24gd2luZG93cw0KPiA+IGNhbiBtYXAgdGhlIGNoaXAgaW50byBh
IGxhcmdlciBzeXN0ZW0gYWRkcmVzcyBzcGFjZSBzdWNoIGFzIHRoZSBSYXBpZElPDQo+IG9yIFBD
SWUgNjQtYml0DQo+ID4gYWRkcmVzcyBlbnZpcm9ubWVudC4gVGhpcyBmdW5jdGlvbmFsaXR5IGlz
IGluY2x1ZGVkIGluIHRoZSBhZGRyZXNzDQo+IHRyYW5zbGF0aW9uIGFuZA0KPiA+IG1hcHBpbmcg
dW5pdHMgKEFUTVVzKS4NCj4gPg0KPiA+ICINCj4gPiBUaGF0IHNob3VsZCBiZSB0aGUgcmVhc29u
IHRvIHNldCB0aGUgRE1BIHdpbmRvdyB0byA0MC1iaXQuDQo+IEkgc2VlLiBIb3dldmVyIGlmIHRo
ZSB0b3AgaGFsZiBvZiB0aGF0IHNwYWNlIGlzbid0IHVzZWQgYnkgZGVmYXVsdCB3aXRoDQo+IHdo
YXRldmVyIGlzIG91ciBjdXJyZW50IHNldHVwLCBpdCBtYWtlcyBzZW5zZSB0byBtb3ZlIGRvd24g
dGhlIDY0LWJpdA0KPiBETUEgd2luZG93IHRvIGFsbG93IHRob3NlIGFkYXB0ZXJzIHRvIGZ1bmN0
aW9uIGRvbid0IHlvdSB0aGluayA/DQpHb29kIHRvIG1lLg0KNDAgYml0IERNQSB3aWxsIHByZXZl
bnQgeW91ciByYWRlb24gdmlkZW8gY2FyZCBmcm9tIHdvcmtpbmcuIFJpZ2h0Pw0KWW91ciBQNTAy
MCBEUyBzeXN0ZW0gb25seSBzdXBwb3J0IDM2IGJpdCBwaHlzaWNhbCBhZGRyZXNzLg0KDQo+IA0K
PiBJJ20gdHJ5aW5nIHRvIHR1cm4gdGhvc2UgRlNMIGJveGVzIGludG8gbmljZSBwcGM2NCBkZXYu
IHdvcmtzdGF0aW9ucyA6LSkNClRoYXQgaXMgZ29vZC4gSSdkIGxpa2UgdG8gc2VlIGhvdyBsb25n
IGl0IHdpbGwgYnVpbGQgYSBrZXJuZWwgLi4uDQp0aGFua3MuDQpSb3kNCg==
^ permalink raw reply
* [PATCH 1/5] powerpc/tm: Fix writing top half of MSR on 32 bit signals
From: Michael Neuling @ 2013-06-07 10:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
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 transactional process and hence the top MSR
bits can contain junk.
This updates the 32 bit signal handling code to always write something to the
top MSR bits so that users know if the process is transactional or not and the
kernel can use it on signal return.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/signal_32.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 201385c..5bc819f 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -407,7 +407,8 @@ inline unsigned long copy_transact_fpr_from_user(struct task_struct *task,
* altivec/spe instructions at some point.
*/
static int save_user_regs(struct pt_regs *regs, struct mcontext __user *frame,
- int sigret, int ctx_has_vsx_region)
+ struct mcontext __user *tm_frame, int sigret,
+ int ctx_has_vsx_region)
{
unsigned long msr = regs->msr;
@@ -475,6 +476,12 @@ static int save_user_regs(struct pt_regs *regs, struct mcontext __user *frame,
if (__put_user(msr, &frame->mc_gregs[PT_MSR]))
return 1;
+ /* We need to write 0 the MSR top 32 bits in the tm frame so that we
+ * can check it on the restore to see if TM is active
+ */
+ if (tm_frame && __put_user(0, &tm_frame->mc_gregs[PT_MSR]))
+ return 1;
+
if (sigret) {
/* Set up the sigreturn trampoline: li r0,sigret; sc */
if (__put_user(0x38000000UL + sigret, &frame->tramp[0])
@@ -952,6 +959,7 @@ int handle_rt_signal32(unsigned long sig, struct k_sigaction *ka,
{
struct rt_sigframe __user *rt_sf;
struct mcontext __user *frame;
+ struct mcontext __user *tm_frame = NULL;
void __user *addr;
unsigned long newsp = 0;
int sigret;
@@ -985,23 +993,24 @@ int handle_rt_signal32(unsigned long sig, struct k_sigaction *ka,
}
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ tm_frame = &rt_sf->uc_transact.uc_mcontext;
if (MSR_TM_ACTIVE(regs->msr)) {
- if (save_tm_user_regs(regs, &rt_sf->uc.uc_mcontext,
- &rt_sf->uc_transact.uc_mcontext, sigret))
+ if (save_tm_user_regs(regs, frame, tm_frame, sigret))
goto badframe;
}
else
#endif
- if (save_user_regs(regs, frame, sigret, 1))
+ {
+ if (save_user_regs(regs, frame, tm_frame, sigret, 1))
goto badframe;
+ }
regs->link = tramp;
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
if (MSR_TM_ACTIVE(regs->msr)) {
if (__put_user((unsigned long)&rt_sf->uc_transact,
&rt_sf->uc.uc_link)
- || __put_user(to_user_ptr(&rt_sf->uc_transact.uc_mcontext),
- &rt_sf->uc_transact.uc_regs))
+ || __put_user((unsigned long)tm_frame, &rt_sf->uc_transact.uc_regs))
goto badframe;
}
else
@@ -1170,7 +1179,7 @@ long sys_swapcontext(struct ucontext __user *old_ctx,
mctx = (struct mcontext __user *)
((unsigned long) &old_ctx->uc_mcontext & ~0xfUL);
if (!access_ok(VERIFY_WRITE, old_ctx, ctx_size)
- || save_user_regs(regs, mctx, 0, ctx_has_vsx_region)
+ || save_user_regs(regs, mctx, NULL, 0, ctx_has_vsx_region)
|| put_sigset_t(&old_ctx->uc_sigmask, ¤t->blocked)
|| __put_user(to_user_ptr(mctx), &old_ctx->uc_regs))
return -EFAULT;
@@ -1392,6 +1401,7 @@ int handle_signal32(unsigned long sig, struct k_sigaction *ka,
{
struct sigcontext __user *sc;
struct sigframe __user *frame;
+ struct mcontext __user *tm_mctx = NULL;
unsigned long newsp = 0;
int sigret;
unsigned long tramp;
@@ -1425,6 +1435,7 @@ int handle_signal32(unsigned long sig, struct k_sigaction *ka,
}
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ tm_mctx = &frame->mctx_transact;
if (MSR_TM_ACTIVE(regs->msr)) {
if (save_tm_user_regs(regs, &frame->mctx, &frame->mctx_transact,
sigret))
@@ -1432,8 +1443,10 @@ int handle_signal32(unsigned long sig, struct k_sigaction *ka,
}
else
#endif
- if (save_user_regs(regs, &frame->mctx, sigret, 1))
+ {
+ if (save_user_regs(regs, &frame->mctx, tm_mctx, sigret, 1))
goto badframe;
+ }
regs->link = tramp;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/5] powerpc/tm: Fix 32 bit non-rt signals
From: Michael Neuling @ 2013-06-07 10:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1370601390-29065-1-git-send-email-mikey@neuling.org>
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 additional state to ptregs so it can be restored.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/signal_32.c | 28 +++++++++++++++++++++++-----
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 5bc819f..5b0fbe2 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -1494,16 +1494,22 @@ badframe:
long sys_sigreturn(int r3, int r4, int r5, int r6, int r7, int r8,
struct pt_regs *regs)
{
+ struct sigframe __user *sf;
struct sigcontext __user *sc;
struct sigcontext sigctx;
struct mcontext __user *sr;
void __user *addr;
sigset_t set;
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ struct mcontext __user *mcp, *tm_mcp;
+ unsigned long msr_hi;
+#endif
/* Always make any pending restarted system calls return -EINTR */
current_thread_info()->restart_block.fn = do_no_restart_syscall;
- sc = (struct sigcontext __user *)(regs->gpr[1] + __SIGNAL_FRAMESIZE);
+ sf = (struct sigframe __user *)(regs->gpr[1] + __SIGNAL_FRAMESIZE);
+ sc = &sf->sctx;
addr = sc;
if (copy_from_user(&sigctx, sc, sizeof(sigctx)))
goto badframe;
@@ -1520,11 +1526,23 @@ long sys_sigreturn(int r3, int r4, int r5, int r6, int r7, int r8,
#endif
set_current_blocked(&set);
- sr = (struct mcontext __user *)from_user_ptr(sigctx.regs);
- addr = sr;
- if (!access_ok(VERIFY_READ, sr, sizeof(*sr))
- || restore_user_regs(regs, sr, 1))
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ mcp = (struct mcontext __user *)&sf->mctx;
+ tm_mcp = (struct mcontext __user *)&sf->mctx_transact;
+ if (__get_user(msr_hi, &tm_mcp->mc_gregs[PT_MSR]))
goto badframe;
+ if MSR_TM_ACTIVE(msr_hi<<32) {
+ if (restore_tm_user_regs(regs, mcp, tm_mcp))
+ goto badframe;
+ } else
+#endif
+ {
+ sr = (struct mcontext __user *)from_user_ptr(sigctx.regs);
+ addr = sr;
+ if (!access_ok(VERIFY_READ, sr, sizeof(*sr))
+ || restore_user_regs(regs, sr, 1))
+ goto badframe;
+ }
set_thread_flag(TIF_RESTOREALL);
return 0;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/5] powerpc/tm: Fix restoration of MSR on 32bit signal return
From: Michael Neuling @ 2013-06-07 10:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1370601390-29065-1-git-send-email-mikey@neuling.org>
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 the stripping of these MSR TM bits.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/signal_32.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 5b0fbe2..b8279b3 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -755,6 +755,7 @@ static long restore_tm_user_regs(struct pt_regs *regs,
{
long err;
unsigned long msr;
+ __u32 msr_hi;
#ifdef CONFIG_VSX
int i;
#endif
@@ -859,8 +860,10 @@ static long restore_tm_user_regs(struct pt_regs *regs,
tm_enable();
/* This loads the checkpointed FP/VEC state, if used */
tm_recheckpoint(¤t->thread, msr);
- /* The task has moved into TM state S, so ensure MSR reflects this */
- regs->msr = (regs->msr & ~MSR_TS_MASK) | MSR_TS_S;
+ /* Retore the top half of the MSR */
+ if (__get_user(msr_hi, &tm_sr->mc_gregs[PT_MSR]))
+ return 1;
+ regs->msr = (regs->msr | (((unsigned long)msr_hi) << 32));
/* This loads the speculative FP/VEC state, if used */
if (msr & MSR_FP) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/5] powerpc/tm: Fix return of 32bit rt signals to active transactions
From: Michael Neuling @ 2013-06-07 10:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1370601390-29065-1-git-send-email-mikey@neuling.org>
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 current code is a legacy of earlier kernel implementations which did
software rollback of active transactions in the kernel. That code has now gone
but we didn't correctly fix up this part of the signals code which still makes
assumptions based on having software rollback.
This changes the signal return code to always restore both contexts on 32 bit
rt signal return.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/signal_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index b8279b3..9e331eb 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -1245,7 +1245,7 @@ long sys_rt_sigreturn(int r3, int r4, int r5, int r6, int r7, int r8,
if (__get_user(msr_hi, &mcp->mc_gregs[PT_MSR]))
goto bad;
- if (MSR_TM_SUSPENDED(msr_hi<<32)) {
+ if (MSR_TM_ACTIVE(msr_hi<<32)) {
/* We only recheckpoint on return if we're
* transaction.
*/
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/5] powerpc/tm: Fix return of active 64bit signals
From: Michael Neuling @ 2013-06-07 10:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1370601390-29065-1-git-send-email-mikey@neuling.org>
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 current code is a legacy of earlier kernel implementations which did
software rollback of active transactions in the kernel. That code has now gone
but we didn't correctly fix up this part of the signals code which still makes
assumptions based on having software rollback.
This changes the signal return code to always restore both contexts on 64 bit
signal return. It also ensures that the MSR TM bits are properly restored from
the signal context which they are not currently.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/signal_64.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index 3459473..887e99d 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -410,6 +410,10 @@ static long restore_tm_sigcontexts(struct pt_regs *regs,
/* get MSR separately, transfer the LE bit if doing signal return */
err |= __get_user(msr, &sc->gp_regs[PT_MSR]);
+ /* pull in MSR TM from user context */
+ regs->msr = (regs->msr & ~MSR_TS_MASK) | (msr & MSR_TS_MASK);
+
+ /* pull in MSR LE from user context */
regs->msr = (regs->msr & ~MSR_LE) | (msr & MSR_LE);
/* The following non-GPR non-FPR non-VR state is also checkpointed: */
@@ -505,8 +509,6 @@ static long restore_tm_sigcontexts(struct pt_regs *regs,
tm_enable();
/* This loads the checkpointed FP/VEC state, if used */
tm_recheckpoint(¤t->thread, msr);
- /* The task has moved into TM state S, so ensure MSR reflects this: */
- regs->msr = (regs->msr & ~MSR_TS_MASK) | __MASK(33);
/* This loads the speculative FP/VEC state, if used */
if (msr & MSR_FP) {
@@ -654,7 +656,7 @@ int sys_rt_sigreturn(unsigned long r3, unsigned long r4, unsigned long r5,
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
if (__get_user(msr, &uc->uc_mcontext.gp_regs[PT_MSR]))
goto badframe;
- if (MSR_TM_SUSPENDED(msr)) {
+ if (MSR_TM_ACTIVE(msr)) {
/* We recheckpoint on return. */
struct ucontext __user *uc_transact;
if (__get_user(uc_transact, &uc->uc_link))
--
1.7.10.4
^ permalink raw reply related
* RE: fsqrt
From: David Laight @ 2013-06-07 10:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Zang Roy-R61911
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Timur Tabi, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777, linuxppc-dev
In-Reply-To: <1370595557.3766.362.camel@pasglop>
> > +
> > +static double crackpot_sqrt(double val)
> > +{
> > + int i;
> > + float x, y;
> > + const float f =3D 1.5F;
> > +
> > + x =3D val * 0.5F;
> > + y =3D val;
> > + i =3D * ( int * ) &y;
> > + i =3D 0x5f3759df - ( i >> 1 );
> > + y =3D * ( float * ) &i;
> > + y =3D y * ( f - ( x * y * y ) );
> > + y =3D y * ( f - ( x * y * y ) );
> > + return val * y;
> > +}
> > +
>=20
> 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 i and y are put in a union.
David
^ permalink raw reply
* Re: [PATCH 17/18] cpufreq: powerpc: move cpufreq driver to drivers/cpufreq
From: Rafael J. Wysocki @ 2013-06-07 11:58 UTC (permalink / raw)
To: Viresh Kumar
Cc: deepthi, Robin Randhawa, linux-pm, patches, Liviu.Dudau,
linux-kernel, cpufreq, Steve.Bannister, Paul Mackerras,
Olof Johansson, Andrew Morton, arvind.chauhan, linuxppc-dev,
linaro-kernel, charles.garcia-tobin
In-Reply-To: <CAKohpom=HvLwn7q9gicJXmHExoaDKKHcgQgT=1F0SKu3N3bXSg@mail.gmail.com>
On Friday, June 07, 2013 10:48:21 AM Viresh Kumar wrote:
> On 31 May 2013 16:20, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 20 May 2013 10:10, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >> On 13 May 2013 11:34, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >>> On 22 April 2013 12:19, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >>>> On 9 April 2013 14:05, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >>>>> On 5 April 2013 12:16, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >>>>>> On 4 April 2013 18:24, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >>>>>>> This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
> >>>>>>>
> >>>>>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >>>>>>> Cc: Paul Mackerras <paulus@samba.org>
> >>>>>>> Cc: Olof Johansson <olof@lixom.net>
> >>>>>>> Cc: linuxppc-dev@lists.ozlabs.org
> >>>>>>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> >>>>>>> ---
> >>>>>>> Compile Tested only.
> >>>>>>>
> >>>>>>> arch/powerpc/platforms/Kconfig | 31 ----------------------
> >>>>>>> arch/powerpc/platforms/pasemi/Makefile | 1 -
> >>>>>>> arch/powerpc/platforms/powermac/Makefile | 2 --
> >>>>>>> drivers/cpufreq/Kconfig.powerpc | 26 ++++++++++++++++++
> >>>>>>> drivers/cpufreq/Makefile | 3 +++
> >>>>>>> .../cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c | 0
> >>>>>>> .../cpufreq/pmac32-cpufreq.c | 0
> >>>>>>> .../cpufreq/pmac64-cpufreq.c | 0
> >>>>>>> 8 files changed, 29 insertions(+), 34 deletions(-)
> >>>>>>> rename arch/powerpc/platforms/pasemi/cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c (100%)
> >>>>>>> rename arch/powerpc/platforms/powermac/cpufreq_32.c => drivers/cpufreq/pmac32-cpufreq.c (100%)
> >>>>>>> rename arch/powerpc/platforms/powermac/cpufreq_64.c => drivers/cpufreq/pmac64-cpufreq.c (100%)
> >>>>>>
> >>>>>> Hi Deepthi,
> >>>>>>
> >>>>>> Can you help testing this please?
> >>>>>
> >>>>> Ping!!
> >>>>
> >>>> Ping!!
> >>>
> >>> Hi Benjamin,
> >>>
> >>> Hope you are back from your vacations. Can you give it a try now?
> >>
> >> Ping!!
> >
> > Ping!!
>
> Hi Rafael,
>
> Its been more than 2 months now that this patch was first posted.
> And the response from Maintainers isn't so great, irrespective of
> how many times I pinged them.
>
> This is what I think:
> - It looked functionally correct to Benjamin but he wanted somebody
> to actually test it.
> - Arnd gave his Ack (So it looked functionally correct to him too)
> - We can probably push this into linux-next now and see if somebody
> complains of any breakage it has done. If not we can get it pushed for
> 3.11.
I agree, applied to bleeding-edge.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: fsqrt
From: Benjamin Herrenschmidt @ 2013-06-07 12:07 UTC (permalink / raw)
To: tiejun.chen
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Zang Roy-R61911, Timur Tabi,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <51B1A18A.6030002@windriver.com>
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 in the kernel ?
> >>
> >> Seems this is already emulated:
> >>
> >> arch/powerpc/math-emu/fsqrt.c
> >>
> >> You can enable CONFIG_MATH_EMULATION to try.
> >
> > Is math emu expected to work at all on top of a real FPU ? I though it
> > didn't ... maybe I'm wrong.
>
> As I understand often the real FPU can't support all float instructions, so we
> have to enable this to emulate those unsupported float instructions in that
> scenario.
Ok, two things come to mind here:
- do_mathemu doesn't do giveup_fpu() so the FPU state might still be
in the "live" FP registers and not in the thread_struct, so it can't
work... unless I missed something.
- mathemu uses solely integers. For something like fsqrt it's going to
suck a lot more than implementing using floating points in the kernel.
Cheers,
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox