* Re: All Applied micro boards are failing with current mainline kernel
From: Josh Boyer @ 2010-11-01 15:39 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Eric Dumazet, Rupjyoti Sarmah, linux-kernel, linuxppc-dev,
David S. Miller, Tom Herbert
In-Reply-To: <20101102023650.bc553e74.sfr@canb.auug.org.au>
On Mon, Nov 1, 2010 at 11:36 AM, Stephen Rothwell <sfr@canb.auug.org.au> wr=
ote:
> Hi Josh,
>
> On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer <jwboyer@gmail.com> wrote:
>>
>> A few hints would be appreciated.
>
> Remove the call to netif_stop_queue() from emac_probe(). =A0Apparently,
> calling this before register_netdev() is now wrong (maybe always was).
Yeah, I just discovered that myself. I'm wondering
1) why we do that in that function?
2) If it needs to be removed entirely, or moved to after the
register_netdev call
3) If the call to netif_carrier_off also needs similar attention.
I can whip up a patch to remove those calls or move them after the
register, but I don't want to do that without knowing which one is
"right".
josh
^ permalink raw reply
* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Timur Tabi @ 2010-11-01 15:46 UTC (permalink / raw)
To: Grant Likely; +Cc: netdev, devicetree-discuss, linuxppc-dev
In-Reply-To: <20101101051734.GB17587@angua.secretlab.ca>
On Mon, Nov 1, 2010 at 12:17 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> Applied, thanks; but made some changes to protect this code because it
> does not work on little endian (it can be fixed in a separate patch)
I'm confused. How does of_get_mac_address() not work on little-endian?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: David Miller @ 2010-11-01 15:50 UTC (permalink / raw)
To: sfr; +Cc: eric.dumazet, rsarmah, linux-kernel, linuxppc-dev, therbert
In-Reply-To: <20101102023650.bc553e74.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 2 Nov 2010 02:36:50 +1100
> Hi Josh,
>
> On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer <jwboyer@gmail.com> wrote:
>>
>> A few hints would be appreciated.
>
> Remove the call to netif_stop_queue() from emac_probe(). Apparently,
> calling this before register_netdev() is now wrong (maybe always was).
Right.
I'll add this to net-2.6
--------------------
ibm_newemac: Remove netif_stop_queue() in emac_probe().
Touching the queue state before register_netdev is not
allowed, and besides the queue state before ->open()
is "don't care"
Reported-by: Josh Boyer <jwboyer@gmail.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ibm_newemac/core.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 385dc32..06bb9b7 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2871,7 +2871,6 @@ static int __devinit emac_probe(struct platform_device *ofdev,
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
netif_carrier_off(ndev);
- netif_stop_queue(ndev);
err = register_netdev(ndev);
if (err) {
--
1.7.3.2
^ permalink raw reply related
* RE: Support for multiple port's
From: Bounine, Alexandre @ 2010-11-01 15:49 UTC (permalink / raw)
To: Thomas Taranowski, linuxppc-dev
In-Reply-To: <AANLkTin7OeSgUgqUEnYxUnZQ0vgckg7e43gudms8NqeG@mail.gmail.com>
Thomas Taranowski wrote:
> Going through the code, it looks like the rapidio driver assumes
> there's only going to be a single Port implemented.
Yes, this is true for the current implementation.
> On the newer QorIQ P2020 processors there are 2 sets of port
> registers, so the current code lays the dbell_atmu_regs structure on
> top of the second set of atmu_regs. There are probably other issues
> as well.
There are issues with multiport support in RIO subsystem code as well .
>=20
> Are there any patch sets available that support the newer processors,
> and multi-port ( multi-homed? ) RapidIO configurations?
I am planning a patch for RIO subsystem - this will not address issues
with FSL mport driver.
>=20
> Thanks!
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: David Miller @ 2010-11-01 15:51 UTC (permalink / raw)
To: jwboyer; +Cc: sfr, eric.dumazet, rsarmah, linux-kernel, linuxppc-dev, therbert
In-Reply-To: <AANLkTin3nsb6FfNtXfqjZCuV66mwKVOsKgmZpTABFDUJ@mail.gmail.com>
From: Josh Boyer <jwboyer@gmail.com>
Date: Mon, 1 Nov 2010 11:39:47 -0400
> On Mon, Nov 1, 2010 at 11:36 AM, Stephen Rothwell <sfr@canb.auug.org.=
au> wrote:
>> Hi Josh,
>>
>> On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer <jwboyer@gmail.com> wro=
te:
>>>
>>> A few hints would be appreciated.
>>
>> Remove the call to netif_stop_queue() from emac_probe(). =A0Apparent=
ly,
>> calling this before register_netdev() is now wrong (maybe always was=
).
> =
> Yeah, I just discovered that myself. I'm wondering
> =
> 1) why we do that in that function?
Because likely it was blindly copied from some other driver.
> 2) If it needs to be removed entirely, or moved to after the
> register_netdev call
Removed entirely.
> 3) If the call to netif_carrier_off also needs similar attention.
Not really.
> I can whip up a patch to remove those calls or move them after the
> register, but I don't want to do that without knowing which one is
> "right".
I've already taken care of this.
^ permalink raw reply
* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Grant Likely @ 2010-11-01 15:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: netdev, devicetree-discuss, linuxppc-dev
In-Reply-To: <AANLkTimp-AFN5T3z9o6X9qM-GQXSU5vinf+Lqu_jUmJj@mail.gmail.com>
On Mon, Nov 1, 2010 at 11:46 AM, Timur Tabi <timur@freescale.com> wrote:
> On Mon, Nov 1, 2010 at 12:17 AM, Grant Likely <grant.likely@secretlab.ca>=
wrote:
>
>> Applied, thanks; but made some changes to protect this code because it
>> does not work on little endian (it can be fixed in a separate patch)
>
> I'm confused. =A0How does of_get_mac_address() not work on little-endian?
Hmmm, right. I got confused here. It should be just fine on
little-endian. I'll revert my change. Thanks.
g.
^ permalink raw reply
* RE: RapidIO: MC Exception when enumerating peer to peer connection
From: Bounine, Alexandre @ 2010-11-01 15:58 UTC (permalink / raw)
To: Thomas Taranowski, Micha Nelissen; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikhcOMexRBVthK8Xr8VTNvDmiUDvWG+QbyzWc38@mail.gmail.com>
Thomas Taranowski wrote:
> Yes, I tried pretty much all combinations of boot order, but I believe
> the preferred approach is to boot the agents first, then the host
> according to my freescale documentation. My problem was that all
> three devices had the same device id. Once I programmed them with
> different device id's via the alternate device id register I could
> finally get doorbell messages across with the jtag.
=20
In the current fsl_rio implementation initialization enables ACCEPT_ALL
mode for the port therefore you should not have problems caused by
initial destID value. Based on your post about multiport support I think
you are close to find a source of the problem.
Are you using any switches in your setup or this is pure board-to-board
configuration?
Alex.
^ permalink raw reply
* PowerQUICC II PCIe dma
From: David Laight @ 2010-11-01 15:58 UTC (permalink / raw)
To: linuxppc-dev
I'm trying to get a ppc 831x to do PCIe dma transfers, PIO transfers
work ok but are somewhat lethargic (partially due to the slave).
I've done the following:
- All reads/writes (including the dma descriptors) are byteswapped.
- Enabled the dma in PEX_CSB_CTRL (value 0x3f)
- Used the kernel physical addresses for all addresses.
For memory from virt_to_phys(), pci from pci_resource_start().
(virt_to_phys() gives invalid values for the pci area).
- I'm setting both 'snoop' bits to 1 (as per the device errata)
So the descriptor 'ctrl' has value (len >> 2) << 12 | 0xff9,
and the dma 'ctrl' 0x401.
- I've put a 'sync' instruction (iosync()) just before the
write to start the dma.
On the first request after hard reset, the dma status register
REX_RDMA_STAT gets set to 4. On subsequent requests it stays zero.
Nothing else appears to happen at all (except the 'start' bit
always reads back zero).
The 'CSB status register' at 0x81c stays zero - so I don't think
it is stuck waiting for the PCIe slave.
I'm not at all sure of the word ordering for the dma descriptor!
Page 14-113 doesn't say! However I've written the values so that
it doesn't matter - once I get a status written back I'll know...
I've probably forgotten something very silly!
Anyone who has got this working any ideas ??
David
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: Josh Boyer @ 2010-11-01 16:14 UTC (permalink / raw)
To: David Miller
Cc: sfr, eric.dumazet, rsarmah, linux-kernel, linuxppc-dev, therbert
In-Reply-To: <20101101.085126.71102684.davem@davemloft.net>
On Mon, Nov 1, 2010 at 11:51 AM, David Miller <davem@davemloft.net> wrote:
>> I can whip up a patch to remove those calls or move them after the
>> register, but I don't want to do that without knowing which one is
>> "right".
>
> I've already taken care of this.
Thanks!
josh
^ permalink raw reply
* Re: RapidIO: MC Exception when enumerating peer to peer connection
From: Micha Nelissen @ 2010-11-01 16:21 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linuxppc-dev, Thomas Taranowski
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552014B9D48@CORPEXCH1.na.ads.idt.com>
Bounine, Alexandre wrote:
> In the current fsl_rio implementation initialization enables ACCEPT_ALL
> mode for the port therefore you should not have problems caused by
> initial destID value. Based on your post about multiport support I think
> you are close to find a source of the problem.
Be aware that accept-all is not enabled from moment of power-on until
boot of kernel. Depending on reset sequence you may or may not notice
the difference.
Micha
^ permalink raw reply
* RE: RapidIO: MC Exception when enumerating peer to peer connection
From: Bounine, Alexandre @ 2010-11-01 16:23 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linuxppc-dev, Thomas Taranowski
In-Reply-To: <4CCEE8FB.2030504@neli.hopto.org>
Micha Nelissen <micha@neli.hopto.org> wrote:
> Bounine, Alexandre wrote:
> > In the current fsl_rio implementation initialization enables
ACCEPT_ALL
> > mode for the port therefore you should not have problems caused by
> > initial destID value. Based on your post about multiport support I
think
> > you are close to find a source of the problem.
>=20
> Be aware that accept-all is not enabled from moment of power-on until
> boot of kernel. Depending on reset sequence you may or may not notice
> the difference.
He mentioned in earlier post that he boots agents first.
^ permalink raw reply
* Re: RapidIO: MC Exception when enumerating peer to peer connection
From: Micha Nelissen @ 2010-11-01 16:24 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linuxppc-dev, Thomas Taranowski
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552014B9D48@CORPEXCH1.na.ads.idt.com>
Bounine, Alexandre wrote:
> In the current fsl_rio implementation initialization enables ACCEPT_ALL
> mode for the port therefore you should not have problems caused by
> initial destID value. Based on your post about multiport support I think
Btw, best is to use 0xFF (or 0xFFFF in 16-bit environment) as
initial/hardware strapped destid, and not change it in any bootloader.
This makes for much stabler kernel enumeration: the host can talk to all
agents with 0xFF initially.
Micha
^ permalink raw reply
* Re: [PATCH] powerpc: kvm: fix information leak to userland
From: Marcelo Tosatti @ 2010-11-01 17:19 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kvm, kernel-janitors, Alexander Graf, kvm-ppc, linux-kernel,
Paul Mackerras, Avi Kivity, linuxppc-dev
In-Reply-To: <1288429464-21763-1-git-send-email-segooon@gmail.com>
On Sat, Oct 30, 2010 at 01:04:24PM +0400, Vasiliy Kulikov wrote:
> Structure kvm_ppc_pvinfo is copied to userland with flags and
> pad fields unitialized. It leads to leaking of contents of
> kernel stack memory.
>
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> ---
> I cannot compile this driver, so it is not tested at all.
>
> arch/powerpc/kvm/powerpc.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
^ permalink raw reply
* Re: [MPC8xx] Initial MMU too low
From: Scott Wood @ 2010-11-01 17:58 UTC (permalink / raw)
To: LEROY christophe; +Cc: linuxppc-dev
In-Reply-To: <4CCC06F8.3020506@c-s.fr>
On Sat, 30 Oct 2010 13:52:24 +0200
LEROY christophe <christophe.leroy@c-s.fr> wrote:
> Hello,
>
> When I build a kernel with DEBUG_LOCK_ALLOC set, I get a kernel which
> has __bss_stop above the C0800000 limit, and then I get a bad page
> exception during the zeroize of the __bss at startup, because the
> initial MMU only maps the first 8Mbytes.
>
> What can I do to fix that ?
Under "Advanced setup", select "Pinned Kernel TLBs". Ignore the "860
ONLY", it applies to all 8xx.
-Scott
^ permalink raw reply
* Re: RapidIO: MC Exception when enumerating peer to peer connection
From: Thomas Taranowski @ 2010-11-01 19:47 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552014B9D48@CORPEXCH1.na.ads.idt.com>
Alex,
Thanks for responses all. This is a pure board-to-board setup. After
further investigation, it's pretty clear now that the issue is due to
my use of multiple ports ( See my other posting conveniently titled
"Support for multiple ports" :) ). Unfortunately, the freescale linux
patchset for the p2020 do nothing to resolve this issue.
On Mon, Nov 1, 2010 at 8:58 AM, Bounine, Alexandre
<Alexandre.Bounine@idt.com> wrote:
> Thomas Taranowski wrote:
>> Yes, I tried pretty much all combinations of boot order, but I believe
>> the preferred approach is to boot the agents first, then the host
>> according to my freescale documentation. =A0My problem was that all
>> three devices had the same device id. =A0Once I programmed them with
>> different device id's via the alternate device id register I could
>> finally get doorbell messages across with the jtag.
>
> In the current fsl_rio implementation initialization enables ACCEPT_ALL
> mode for the port therefore you should not have problems caused by
> initial destID value. Based on your post about multiport support I think
> you are close to find a source of the problem.
>
> Are you using any switches in your setup or this is pure board-to-board
> configuration?
>
> Alex.
>
>
^ permalink raw reply
* RapidIO: git tree for tracking latest
From: Thomas Taranowski @ 2010-11-01 19:53 UTC (permalink / raw)
To: linuxppc-dev
Is there an official maintainer's repository for RapidIO related
changes to I should be tracking? I've been tracking Kumar's git
repository (off kernel.org), but I'm not clear on who the keeper of
this stuff is.
Thanks!
Thomas Taranowski
Certified netburner consultant
baringforge.com
^ permalink raw reply
* Re: [PATCH] iSeries: Don't leak if allocations fail in mf_getSrcHistory
From: Stephen Rothwell @ 2010-11-01 20:10 UTC (permalink / raw)
To: michael
Cc: linuxppc-dev, Jesper Juhl, Paul Mackerras, linux-kernel,
Stephen Rothwell
In-Reply-To: <1288609842.10671.7.camel@concordia>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
Hi Jesper,
On Mon, 01 Nov 2010 22:10:42 +1100 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> On Sat, 2010-10-30 at 19:20 +0200, Jesper Juhl wrote:
> >
> > If memory is tight and a dynamic allocation fails there's no reason to
> > make a bad situation worse by leaking memory.
> >
> > mf_getSrcHistory potentially leaks pages[0-3]. I believe the right thing
> > to do is to free that memory again before returning -ENOMEM - which is
> > what this patch does.
> >
> > I realize that the function is under '#if 0' so this probably doesn't
> > matter much, but I assume that the function is still there for a reason
> > (but I could be wrong, I don't know the powerpc code).
> > Anyway, I suggest we remove the leak.
>
> Stephen is the iSeries maintainer, and I think he #if 0'ed the code. But
> I don't think it will ever be un-ifdef'ed, so should probably just be
> removed.
Well, only unofficially iseries maintainer :-)
Yes, just remove the whole function ... it was never used and never will
be.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] iSeries: Remove unused mf_getSrcHistory function.
From: Jesper Juhl @ 2010-11-01 20:06 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linuxppc-dev, Paul Mackerras, linux-kernel, Stephen Rothwell
In-Reply-To: <20101102071025.2fe5e6ca.sfr@canb.auug.org.au>
On Tue, 2 Nov 2010, Stephen Rothwell wrote:
> Hi Jesper,
>
> On Mon, 01 Nov 2010 22:10:42 +1100 Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > On Sat, 2010-10-30 at 19:20 +0200, Jesper Juhl wrote:
> > >
> > > If memory is tight and a dynamic allocation fails there's no reason to
> > > make a bad situation worse by leaking memory.
> > >
> > > mf_getSrcHistory potentially leaks pages[0-3]. I believe the right thing
> > > to do is to free that memory again before returning -ENOMEM - which is
> > > what this patch does.
> > >
> > > I realize that the function is under '#if 0' so this probably doesn't
> > > matter much, but I assume that the function is still there for a reason
> > > (but I could be wrong, I don't know the powerpc code).
> > > Anyway, I suggest we remove the leak.
> >
> > Stephen is the iSeries maintainer, and I think he #if 0'ed the code. But
> > I don't think it will ever be un-ifdef'ed, so should probably just be
> > removed.
>
> Well, only unofficially iseries maintainer :-)
>
> Yes, just remove the whole function ... it was never used and never will
> be.
>
Done.
Remove unused function 'mf_getSrcHistory' (that will never be used ever
according to Stephen Rothwell).
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
mf.c | 46 ----------------------------------------------
1 file changed, 46 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/mf.c b/arch/powerpc/platforms/iseries/mf.c
index 42d0a88..56cfd8c 100644
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -1045,52 +1045,6 @@ static const struct file_operations mf_side_proc_fops = {
.write = mf_side_proc_write,
};
-#if 0
-static void mf_getSrcHistory(char *buffer, int size)
-{
- struct IplTypeReturnStuff return_stuff;
- struct pending_event *ev = new_pending_event();
- int rc = 0;
- char *pages[4];
-
- pages[0] = kmalloc(4096, GFP_ATOMIC);
- pages[1] = kmalloc(4096, GFP_ATOMIC);
- pages[2] = kmalloc(4096, GFP_ATOMIC);
- pages[3] = kmalloc(4096, GFP_ATOMIC);
- if ((ev == NULL) || (pages[0] == NULL) || (pages[1] == NULL)
- || (pages[2] == NULL) || (pages[3] == NULL))
- return -ENOMEM;
-
- return_stuff.xType = 0;
- return_stuff.xRc = 0;
- return_stuff.xDone = 0;
- ev->event.hp_lp_event.xSubtype = 6;
- ev->event.hp_lp_event.x.xSubtypeData =
- subtype_data('M', 'F', 'V', 'I');
- ev->event.data.vsp_cmd.xEvent = &return_stuff;
- ev->event.data.vsp_cmd.cmd = 4;
- ev->event.data.vsp_cmd.lp_index = HvLpConfig_getLpIndex();
- ev->event.data.vsp_cmd.result_code = 0xFF;
- ev->event.data.vsp_cmd.reserved = 0;
- ev->event.data.vsp_cmd.sub_data.page[0] = iseries_hv_addr(pages[0]);
- ev->event.data.vsp_cmd.sub_data.page[1] = iseries_hv_addr(pages[1]);
- ev->event.data.vsp_cmd.sub_data.page[2] = iseries_hv_addr(pages[2]);
- ev->event.data.vsp_cmd.sub_data.page[3] = iseries_hv_addr(pages[3]);
- mb();
- if (signal_event(ev) != 0)
- return;
-
- while (return_stuff.xDone != 1)
- udelay(10);
- if (return_stuff.xRc == 0)
- memcpy(buffer, pages[0], size);
- kfree(pages[0]);
- kfree(pages[1]);
- kfree(pages[2]);
- kfree(pages[3]);
-}
-#endif
-
static int mf_src_proc_show(struct seq_file *m, void *v)
{
#if 0
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* Re: [PATCH v3] add icswx support
From: Michael Neuling @ 2010-11-01 21:11 UTC (permalink / raw)
To: Tseng-Hui (Frank) Lin; +Cc: tsenglin, linuxppc-dev
In-Reply-To: <1287547340.14049.25.camel@flin.austin.ibm.com>
In message <1287547340.14049.25.camel@flin.austin.ibm.com> you wrote:
> icswx is a PowerPC co-processor instruction to send data to a
> co-processor. On Book-S processors the LPAR_ID and process ID (PID) of
> the owning process are registered in the window context of the
> co-processor at initial time. When the icswx instruction is executed,
> the L2 generates a cop-reg transaction on PowerBus. The transaction has
> no address and the processor does not perform an MMU access to
> authenticate the transaction. The coprocessor compares the LPAR_ID and
> the PID included in the transaction and the LPAR_ID and PID held in the
> window context to determine if the process is authorized to generate the
> transaction.
>
> The OS needs to assign a 16-bit PID for the process. This cop-PID needs
> to be updated during context switch. The cop-PID needs to be destroyed
> when the context is destroyed.
>
> Change log from v2:
> - Make the code a CPU feature and return -NODEV if CPU doesn't have
> icswx co-processor instruction.
> - Change the goto loop in use_cop() into a do-while loop.
> - Change context destroy code into a new destroy_context_acop() function
> and #define it based on CONFIG_ICSWX.
> - Remove mmput() from drop_cop().
> - Fix some TAB/space problems.
>
> Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
> Signed-off-by: Tseng-Hui (Frank) Lin <thlin@linux.vnet.ibm.com>
This is white space munged again.
Mikey
>
> ---
> arch/powerpc/include/asm/cputable.h | 4 +-
> arch/powerpc/include/asm/mmu-hash64.h | 5 ++
> arch/powerpc/include/asm/mmu_context.h | 6 ++
> arch/powerpc/include/asm/reg.h | 11 +++
> arch/powerpc/include/asm/reg_booke.h | 3 -
> arch/powerpc/mm/mmu_context_hash64.c | 109
> ++++++++++++++++++++++++++++++++
> arch/powerpc/platforms/Kconfig.cputype | 17 +++++
> 7 files changed, 151 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cputable.h
> b/arch/powerpc/include/asm/cputable.h
> index 3a40a99..bbb4e2c 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -198,6 +198,7 @@ extern const char *powerpc_base_platform;
> #define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040000000000000)
> #define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080000000000000)
> #define CPU_FTR_ASYM_SMT LONG_ASM_CONST(0x0100000000000000)
> +#define CPU_FTR_ICSWX LONG_ASM_CONST(0x02000000000000
00)
>
> #ifndef __ASSEMBLY__
>
> @@ -413,7 +414,8 @@ extern const char *powerpc_base_platform;
> CPU_FTR_MMCRA | CPU_FTR_SMT | \
> CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
> CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
> - CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT)
> + CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT | \
> + CPU_FTR_ICSWX)
> #define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
> CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h
> b/arch/powerpc/include/asm/mmu-hash64.h
> index acac35d..6c1ab90 100644
> --- a/arch/powerpc/include/asm/mmu-hash64.h
> +++ b/arch/powerpc/include/asm/mmu-hash64.h
> @@ -423,6 +423,11 @@ typedef struct {
> #ifdef CONFIG_PPC_SUBPAGE_PROT
> struct subpage_prot_table spt;
> #endif /* CONFIG_PPC_SUBPAGE_PROT */
> +#ifdef CONFIG_ICSWX
> + unsigned long acop; /* mask of enabled coprocessor types */
> +#define HASH64_MAX_PID (0xFFFF)
> + unsigned int acop_pid; /* pid value used with coprocessors */
> +#endif /* CONFIG_ICSWX */
> } mm_context_t;
>
>
> diff --git a/arch/powerpc/include/asm/mmu_context.h
> b/arch/powerpc/include/asm/mmu_context.h
> index 81fb412..88118de 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -80,6 +80,12 @@ static inline void switch_mm(struct mm_struct *prev,
> struct mm_struct *next,
>
> #define deactivate_mm(tsk,mm) do { } while (0)
>
> +#ifdef CONFIG_ICSWX
> +extern void switch_cop(struct mm_struct *next);
> +extern int use_cop(unsigned long acop, struct mm_struct *mm);
> +extern void drop_cop(unsigned long acop, struct mm_struct *mm);
> +#endif /* CONFIG_ICSWX */
> +
> /*
> * After we have set current->mm to a new value, this activates
> * the context for the new mm so we see the new mappings.
> diff --git a/arch/powerpc/include/asm/reg.h
> b/arch/powerpc/include/asm/reg.h
> index ff0005eec..b86d876 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -170,8 +170,19 @@
> #define SPEFSCR_FRMC 0x00000003 /* Embedded FP rounding mode co
ntrol
> */
>
> /* Special Purpose Registers (SPRNs)*/
> +
> +#ifdef CONFIG_40x
> +#define SPRN_PID 0x3B1 /* Process ID */
> +#else
> +#define SPRN_PID 0x030 /* Process ID */
> +#ifdef CONFIG_BOOKE
> +#define SPRN_PID0 SPRN_PID/* Process ID Register 0 */
> +#endif
> +#endif
> +
> #define SPRN_CTR 0x009 /* Count Register */
> #define SPRN_DSCR 0x11
> +#define SPRN_ACOP 0x1F /* Available Coprocessor Register */
> #define SPRN_CTRLF 0x088
> #define SPRN_CTRLT 0x098
> #define CTRL_CT 0xc0000000 /* current thread */
> diff --git a/arch/powerpc/include/asm/reg_booke.h
> b/arch/powerpc/include/asm/reg_booke.h
> index 667a498..5b0c781 100644
> --- a/arch/powerpc/include/asm/reg_booke.h
> +++ b/arch/powerpc/include/asm/reg_booke.h
> @@ -150,8 +150,6 @@
> * or IBM 40x.
> */
> #ifdef CONFIG_BOOKE
> -#define SPRN_PID 0x030 /* Process ID */
> -#define SPRN_PID0 SPRN_PID/* Process ID Register 0 */
> #define SPRN_CSRR0 0x03A /* Critical Save and Restore Register 0 */
> #define SPRN_CSRR1 0x03B /* Critical Save and Restore Register 1 */
> #define SPRN_DEAR 0x03D /* Data Error Address Register */
> @@ -168,7 +166,6 @@
> #define SPRN_TCR 0x154 /* Timer Control Register */
> #endif /* Book E */
> #ifdef CONFIG_40x
> -#define SPRN_PID 0x3B1 /* Process ID */
> #define SPRN_DBCR1 0x3BD /* Debug Control Register 1 */
> #define SPRN_ESR 0x3D4 /* Exception Syndrome Register */
> #define SPRN_DEAR 0x3D5 /* Data Error Address Register */
> diff --git a/arch/powerpc/mm/mmu_context_hash64.c
> b/arch/powerpc/mm/mmu_context_hash64.c
> index 2535828..6ef6ce2 100644
> --- a/arch/powerpc/mm/mmu_context_hash64.c
> +++ b/arch/powerpc/mm/mmu_context_hash64.c
> @@ -18,6 +18,7 @@
> #include <linux/mm.h>
> #include <linux/spinlock.h>
> #include <linux/idr.h>
> +#include <linux/percpu.h>
> #include <linux/module.h>
> #include <linux/gfp.h>
>
> @@ -26,6 +27,113 @@
> static DEFINE_SPINLOCK(mmu_context_lock);
> static DEFINE_IDA(mmu_context_ida);
>
> +#ifdef CONFIG_ICSWX
> +static DEFINE_SPINLOCK(mmu_context_acop_lock);
> +static DEFINE_IDA(cop_ida);
> +
> +/* Lazy switch the ACOP register */
> +static DEFINE_PER_CPU(unsigned long, acop_reg);
> +
> +void switch_cop(struct mm_struct *next)
> +{
> + if (!cpu_has_feature(CPU_FTR_ICSWX))
> + return;
> +
> + mtspr(SPRN_PID, next->context.acop_pid);
> + if (next->context.acop_pid &&
> + __get_cpu_var(acop_reg) != next->context.acop) {
> + mtspr(SPRN_ACOP, next->context.acop);
> + __get_cpu_var(acop_reg) = next->context.acop;
> + }
> +}
> +EXPORT_SYMBOL(switch_cop);
> +
> +int use_cop(unsigned long acop, struct mm_struct *mm)
> +{
> + int acop_pid;
> + int err;
> +
> + if (!cpu_has_feature(CPU_FTR_ICSWX))
> + return -ENODEV;
> +
> + if (!mm)
> + return -EINVAL;
> +
> + if (!mm->context.acop_pid) {
> + if (!ida_pre_get(&cop_ida, GFP_KERNEL))
> + return -ENOMEM;
> + do {
> + spin_lock(&mmu_context_acop_lock);
> + err = ida_get_new_above(&cop_ida, 1, &acop_pid);
> + spin_unlock(&mmu_context_acop_lock);
> + } while (err == -EAGAIN);
> +
> + if (err)
> + return err;
> +
> + if (acop_pid > HASH64_MAX_PID) {
> + spin_lock(&mmu_context_acop_lock);
> + ida_remove(&cop_ida, acop_pid);
> + spin_unlock(&mmu_context_acop_lock);
> + return -EBUSY;
> + }
> + mm->context.acop_pid = acop_pid;
> + if (mm == current->active_mm)
> + mtspr(SPRN_PID, mm->context.acop_pid);
> + }
> + spin_lock(&mmu_context_acop_lock);
> + mm->context.acop |= acop;
> + spin_unlock(&mmu_context_acop_lock);
> +
> + get_cpu_var(acop_reg) = mm->context.acop;
> + if (mm == current->active_mm)
> + mtspr(SPRN_ACOP, mm->context.acop);
> + put_cpu_var(acop_reg);
> +
> + return mm->context.acop_pid;
> +}
> +EXPORT_SYMBOL(use_cop);
> +
> +void drop_cop(unsigned long acop, struct mm_struct *mm)
> +{
> + if (!cpu_has_feature(CPU_FTR_ICSWX))
> + return;
> +
> + if (WARN_ON(!mm))
> + return;
> +
> + spin_lock(&mmu_context_acop_lock);
> + mm->context.acop &= ~acop;
> + spin_unlock(&mmu_context_acop_lock);
> + if (!mm->context.acop) {
> + spin_lock(&mmu_context_acop_lock);
> + ida_remove(&cop_ida, mm->context.acop_pid);
> + spin_unlock(&mmu_context_acop_lock);
> + mm->context.acop_pid = 0;
> + if (mm == current->active_mm)
> + mtspr(SPRN_PID, mm->context.acop_pid);
> + } else {
> + get_cpu_var(acop_reg) = mm->context.acop;
> + if (mm == current->active_mm)
> + mtspr(SPRN_ACOP, mm->context.acop);
> + put_cpu_var(acop_reg);
> + }
> +}
> +EXPORT_SYMBOL(drop_cop);
> +
> +static void destroy_context_acop(struct mm_struct *mm)
> +{
> + if (mm->context.acop_pid) {
> + spin_lock(&mmu_context_acop_lock);
> + ida_remove(&cop_ida, mm->context.acop_pid);
> + spin_unlock(&mmu_context_acop_lock);
> + }
> +}
> +
> +#else
> +#define destroy_context_acop(mm)
> +#endif /* CONFIG_ICSWX */
> +
> /*
> * The proto-VSID space has 2^35 - 1 segments available for user
> mappings.
> * Each segment contains 2^28 bytes. Each context maps 2^44 bytes,
> @@ -93,6 +201,7 @@ EXPORT_SYMBOL_GPL(__destroy_context);
>
> void destroy_context(struct mm_struct *mm)
> {
> + destroy_context_acop(mm);
> __destroy_context(mm->context.id);
> subpage_prot_free(mm);
> mm->context.id = NO_CONTEXT;
> diff --git a/arch/powerpc/platforms/Kconfig.cputype
> b/arch/powerpc/platforms/Kconfig.cputype
> index d361f81..7678e29 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -220,6 +220,23 @@ config VSX
>
> If in doubt, say Y here.
>
> +config ICSWX
> + bool "Support for PowerPC icswx co-processor instruction"
> + depends on POWER4
> + default n
> + ---help---
> +
> + Enabling this option to turn on the PowerPC icswx co-processor
> + instruction support for POWER7 or newer processors.
> + This option is only useful if you have a processor that supports
> + icswx co-processor instruction. It does not have any effect on
> + processors without icswx co-processor instruction.
> +
> + This support slightly increases kernel memory usage.
> +
> + Say N if you do not have a PowerPC processor supporting icswx
> + instruction and a PowerPC co-processor.
> +
> config SPE
> bool "SPE Support"
> depends on E200 || (E500 && !PPC_E500MC)
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] iSeries: Remove unused mf_getSrcHistory function.
From: Stephen Rothwell @ 2010-11-01 21:26 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1011012104050.12889@swampdragon.chaosbits.net>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On Mon, 1 Nov 2010 21:06:23 +0100 (CET) Jesper Juhl <jj@chaosbits.net> wrote:
>
> Remove unused function 'mf_getSrcHistory' (that will never be used ever
> according to Stephen Rothwell).
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] iSeries: Remove unused mf_getSrcHistory function.
From: Jesper Juhl @ 2010-11-01 21:20 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20101102082634.65342ce6.sfr@canb.auug.org.au>
Hi Stephen,
On Tue, 2 Nov 2010, Stephen Rothwell wrote:
> On Mon, 1 Nov 2010 21:06:23 +0100 (CET) Jesper Juhl <jj@chaosbits.net> wrote:
> >
> > Remove unused function 'mf_getSrcHistory' (that will never be used ever
> > according to Stephen Rothwell).
> >
> > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
>
> Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
Ok, so if you are the (unofficial) iSeries maintainer and you don't merge
the patch somewhere that'll eventually go up-stream, but just ACK it
(thank you for that btw), then where do I send it to get it merged?
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply
* Re: [PATCH v3] add icswx support
From: Michael Neuling @ 2010-11-01 22:23 UTC (permalink / raw)
To: Tseng-Hui (Frank) Lin; +Cc: tsenglin, linuxppc-dev
In-Reply-To: <1287547340.14049.25.camel@flin.austin.ibm.com>
In message <1287547340.14049.25.camel@flin.austin.ibm.com> you wrote:
> icswx is a PowerPC co-processor instruction to send data to a
> co-processor. On Book-S processors the LPAR_ID and process ID (PID) of
> the owning process are registered in the window context of the
> co-processor at initial time. When the icswx instruction is executed,
> the L2 generates a cop-reg transaction on PowerBus. The transaction has
> no address and the processor does not perform an MMU access to
> authenticate the transaction. The coprocessor compares the LPAR_ID and
> the PID included in the transaction and the LPAR_ID and PID held in the
> window context to determine if the process is authorized to generate the
> transaction.
>
> The OS needs to assign a 16-bit PID for the process. This cop-PID needs
> to be updated during context switch. The cop-PID needs to be destroyed
> when the context is destroyed.
>
> Change log from v2:
> - Make the code a CPU feature and return -NODEV if CPU doesn't have
> icswx co-processor instruction.
> - Change the goto loop in use_cop() into a do-while loop.
> - Change context destroy code into a new destroy_context_acop() function
> and #define it based on CONFIG_ICSWX.
> - Remove mmput() from drop_cop().
> - Fix some TAB/space problems.
>
> Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
> Signed-off-by: Tseng-Hui (Frank) Lin <thlin@linux.vnet.ibm.com>
>
> ---
> arch/powerpc/include/asm/cputable.h | 4 +-
> arch/powerpc/include/asm/mmu-hash64.h | 5 ++
> arch/powerpc/include/asm/mmu_context.h | 6 ++
> arch/powerpc/include/asm/reg.h | 11 +++
> arch/powerpc/include/asm/reg_booke.h | 3 -
> arch/powerpc/mm/mmu_context_hash64.c | 109
> ++++++++++++++++++++++++++++++++
> arch/powerpc/platforms/Kconfig.cputype | 17 +++++
> 7 files changed, 151 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cputable.h
> b/arch/powerpc/include/asm/cputable.h
> index 3a40a99..bbb4e2c 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -198,6 +198,7 @@ extern const char *powerpc_base_platform;
> #define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040000000000000)
> #define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080000000000000)
> #define CPU_FTR_ASYM_SMT LONG_ASM_CONST(0x0100000000000000)
> +#define CPU_FTR_ICSWX LONG_ASM_CONST(0x02000000000000
00)
>
> #ifndef __ASSEMBLY__
>
> @@ -413,7 +414,8 @@ extern const char *powerpc_base_platform;
> CPU_FTR_MMCRA | CPU_FTR_SMT | \
> CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
> CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
> - CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT)
> + CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT | \
> + CPU_FTR_ICSWX)
You patch is against an old kernel. POWER7 doesn't look like this
anymore. Please update to newer kernel. I'd suggest patching against
linux-next.
We probabbly need to set a cpu_user_feature too so userspace knows it
can use this. We need to create a PPC_FEATURE_HAS_ICSWX. Frank: just
follow the bouncing ball on PPC_FEATURE_HAS_VSX.
> #define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
> CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h
> b/arch/powerpc/include/asm/mmu-hash64.h
> index acac35d..6c1ab90 100644
> --- a/arch/powerpc/include/asm/mmu-hash64.h
> +++ b/arch/powerpc/include/asm/mmu-hash64.h
> @@ -423,6 +423,11 @@ typedef struct {
> #ifdef CONFIG_PPC_SUBPAGE_PROT
> struct subpage_prot_table spt;
> #endif /* CONFIG_PPC_SUBPAGE_PROT */
> +#ifdef CONFIG_ICSWX
> + unsigned long acop; /* mask of enabled coprocessor types */
> +#define HASH64_MAX_PID (0xFFFF)
> + unsigned int acop_pid; /* pid value used with coprocessors */
> +#endif /* CONFIG_ICSWX */
> } mm_context_t;
>
>
> diff --git a/arch/powerpc/include/asm/mmu_context.h
> b/arch/powerpc/include/asm/mmu_context.h
> index 81fb412..88118de 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -80,6 +80,12 @@ static inline void switch_mm(struct mm_struct *prev,
> struct mm_struct *next,
>
> #define deactivate_mm(tsk,mm) do { } while (0)
>
> +#ifdef CONFIG_ICSWX
> +extern void switch_cop(struct mm_struct *next);
> +extern int use_cop(unsigned long acop, struct mm_struct *mm);
> +extern void drop_cop(unsigned long acop, struct mm_struct *mm);
> +#endif /* CONFIG_ICSWX */
> +
> /*
> * After we have set current->mm to a new value, this activates
> * the context for the new mm so we see the new mappings.
> diff --git a/arch/powerpc/include/asm/reg.h
> b/arch/powerpc/include/asm/reg.h
> index ff0005eec..b86d876 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -170,8 +170,19 @@
> #define SPEFSCR_FRMC 0x00000003 /* Embedded FP rounding mode co
ntrol
> */
>
> /* Special Purpose Registers (SPRNs)*/
> +
> +#ifdef CONFIG_40x
> +#define SPRN_PID 0x3B1 /* Process ID */
> +#else
> +#define SPRN_PID 0x030 /* Process ID */
> +#ifdef CONFIG_BOOKE
> +#define SPRN_PID0 SPRN_PID/* Process ID Register 0 */
> +#endif
> +#endif
> +
> #define SPRN_CTR 0x009 /* Count Register */
> #define SPRN_DSCR 0x11
> +#define SPRN_ACOP 0x1F /* Available Coprocessor Register */
> #define SPRN_CTRLF 0x088
> #define SPRN_CTRLT 0x098
> #define CTRL_CT 0xc0000000 /* current thread */
> diff --git a/arch/powerpc/include/asm/reg_booke.h
> b/arch/powerpc/include/asm/reg_booke.h
> index 667a498..5b0c781 100644
> --- a/arch/powerpc/include/asm/reg_booke.h
> +++ b/arch/powerpc/include/asm/reg_booke.h
> @@ -150,8 +150,6 @@
> * or IBM 40x.
> */
> #ifdef CONFIG_BOOKE
> -#define SPRN_PID 0x030 /* Process ID */
> -#define SPRN_PID0 SPRN_PID/* Process ID Register 0 */
> #define SPRN_CSRR0 0x03A /* Critical Save and Restore Register 0 */
> #define SPRN_CSRR1 0x03B /* Critical Save and Restore Register 1 */
> #define SPRN_DEAR 0x03D /* Data Error Address Register */
> @@ -168,7 +166,6 @@
> #define SPRN_TCR 0x154 /* Timer Control Register */
> #endif /* Book E */
> #ifdef CONFIG_40x
> -#define SPRN_PID 0x3B1 /* Process ID */
> #define SPRN_DBCR1 0x3BD /* Debug Control Register 1 */
> #define SPRN_ESR 0x3D4 /* Exception Syndrome Register */
> #define SPRN_DEAR 0x3D5 /* Data Error Address Register */
> diff --git a/arch/powerpc/mm/mmu_context_hash64.c
> b/arch/powerpc/mm/mmu_context_hash64.c
> index 2535828..6ef6ce2 100644
> --- a/arch/powerpc/mm/mmu_context_hash64.c
> +++ b/arch/powerpc/mm/mmu_context_hash64.c
> @@ -18,6 +18,7 @@
> #include <linux/mm.h>
> #include <linux/spinlock.h>
> #include <linux/idr.h>
> +#include <linux/percpu.h>
> #include <linux/module.h>
> #include <linux/gfp.h>
>
> @@ -26,6 +27,113 @@
> static DEFINE_SPINLOCK(mmu_context_lock);
> static DEFINE_IDA(mmu_context_ida);
>
> +#ifdef CONFIG_ICSWX
> +static DEFINE_SPINLOCK(mmu_context_acop_lock);
> +static DEFINE_IDA(cop_ida);
> +
> +/* Lazy switch the ACOP register */
> +static DEFINE_PER_CPU(unsigned long, acop_reg);
Do we really need to do this lazily? Do you have any performance
numbers to say this is needed?
Why do the ACOP lazily and no the PID?
> +
> +void switch_cop(struct mm_struct *next)
> +{
> + if (!cpu_has_feature(CPU_FTR_ICSWX))
> + return;
> +
> + mtspr(SPRN_PID, next->context.acop_pid);
> + if (next->context.acop_pid &&
> + __get_cpu_var(acop_reg) != next->context.acop) {
> + mtspr(SPRN_ACOP, next->context.acop);
> + __get_cpu_var(acop_reg) = next->context.acop;
> + }
Does SPRN_PID need to be switch on normal context in __switch_to? What
happens when a CPU context switches to another process that is also
doing ICSWX? Don't we need to update the PID so if that process does an
ICSWX it sends the correct PID?
What context is this going to get called in? Could we get pre-empted
here and end up doing one of these and not the other and then coming
back in again? You use a lock later when updating ACP, but not here?
Why is that?
Again, what is the justfication for the lazy switching complexity?
Also, I'd like to see an example user for this interface. You created
three new interfaces but provided no examples and no documentation on
how to use them:
+EXPORT_SYMBOL(switch_cop);
+EXPORT_SYMBOL(use_cop);
+EXPORT_SYMBOL(drop_cop);
Please document how to use these.
> +}
> +EXPORT_SYMBOL(switch_cop);
> +
> +int use_cop(unsigned long acop, struct mm_struct *mm)
> +{
> + int acop_pid;
> + int err;
> +
> + if (!cpu_has_feature(CPU_FTR_ICSWX))
> + return -ENODEV;
> +
> + if (!mm)
> + return -EINVAL;
> +
> + if (!mm->context.acop_pid) {
> + if (!ida_pre_get(&cop_ida, GFP_KERNEL))
> + return -ENOMEM;
> + do {
> + spin_lock(&mmu_context_acop_lock);
> + err = ida_get_new_above(&cop_ida, 1, &acop_pid);
> + spin_unlock(&mmu_context_acop_lock);
> + } while (err == -EAGAIN);
ida_get_new_above says this:
* If memory is required, it will return %-EAGAIN, you should unlock
* and go back to the ida_pre_get() call. If the ida is full, it will
* return %-ENOSPC.
You are not going back to ida_pre_get().
> +
> + if (err)
> + return err;
> +
> + if (acop_pid > HASH64_MAX_PID) {
> + spin_lock(&mmu_context_acop_lock);
> + ida_remove(&cop_ida, acop_pid);
> + spin_unlock(&mmu_context_acop_lock);
> + return -EBUSY;
> + }
> + mm->context.acop_pid = acop_pid;
> + if (mm == current->active_mm)
> + mtspr(SPRN_PID, mm->context.acop_pid);
> + }
> + spin_lock(&mmu_context_acop_lock);
> + mm->context.acop |= acop;
> + spin_unlock(&mmu_context_acop_lock);
> +
> + get_cpu_var(acop_reg) = mm->context.acop;
> + if (mm == current->active_mm)
> + mtspr(SPRN_ACOP, mm->context.acop);
> + put_cpu_var(acop_reg);
> +
> + return mm->context.acop_pid;
> +}
> +EXPORT_SYMBOL(use_cop);
> +
> +void drop_cop(unsigned long acop, struct mm_struct *mm)
> +{
> + if (!cpu_has_feature(CPU_FTR_ICSWX))
> + return;
> +
> + if (WARN_ON(!mm))
> + return;
> +
> + spin_lock(&mmu_context_acop_lock);
> + mm->context.acop &= ~acop;
> + spin_unlock(&mmu_context_acop_lock);
> + if (!mm->context.acop) {
> + spin_lock(&mmu_context_acop_lock);
> + ida_remove(&cop_ida, mm->context.acop_pid);
> + spin_unlock(&mmu_context_acop_lock);
> + mm->context.acop_pid = 0;
Is the locking right here? Should this last line be inside the lock?
> + if (mm == current->active_mm)
> + mtspr(SPRN_PID, mm->context.acop_pid);
PID will now be 0. What happens in a userspace program does a ICSWX
with PID 0?
> + } else {
> + get_cpu_var(acop_reg) = mm->context.acop;
> + if (mm == current->active_mm)
> + mtspr(SPRN_ACOP, mm->context.acop);
> + put_cpu_var(acop_reg);
> + }
> +}
> +EXPORT_SYMBOL(drop_cop);
> +
> +static void destroy_context_acop(struct mm_struct *mm)
> +{
> + if (mm->context.acop_pid) {
> + spin_lock(&mmu_context_acop_lock);
> + ida_remove(&cop_ida, mm->context.acop_pid);
> + spin_unlock(&mmu_context_acop_lock);
> + }
> +}
> +
> +#else
> +#define destroy_context_acop(mm)
> +#endif /* CONFIG_ICSWX */
> +
> /*
> * The proto-VSID space has 2^35 - 1 segments available for user
> mappings.
> * Each segment contains 2^28 bytes. Each context maps 2^44 bytes,
> @@ -93,6 +201,7 @@ EXPORT_SYMBOL_GPL(__destroy_context);
>
> void destroy_context(struct mm_struct *mm)
> {
> + destroy_context_acop(mm);
> __destroy_context(mm->context.id);
> subpage_prot_free(mm);
> mm->context.id = NO_CONTEXT;
> diff --git a/arch/powerpc/platforms/Kconfig.cputype
> b/arch/powerpc/platforms/Kconfig.cputype
> index d361f81..7678e29 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -220,6 +220,23 @@ config VSX
>
> If in doubt, say Y here.
>
> +config ICSWX
> + bool "Support for PowerPC icswx co-processor instruction"
> + depends on POWER4
> + default n
> + ---help---
> +
> + Enabling this option to turn on the PowerPC icswx co-processor
> + instruction support for POWER7 or newer processors.
> + This option is only useful if you have a processor that supports
> + icswx co-processor instruction. It does not have any effect on
> + processors without icswx co-processor instruction.
> +
> + This support slightly increases kernel memory usage.
> +
> + Say N if you do not have a PowerPC processor supporting icswx
> + instruction and a PowerPC co-processor.
> +
> config SPE
> bool "SPE Support"
> depends on E200 || (E500 && !PPC_E500MC)
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH v3] add icswx support
From: Benjamin Herrenschmidt @ 2010-11-01 22:31 UTC (permalink / raw)
To: Michael Neuling; +Cc: tsenglin, linuxppc-dev, Tseng-Hui (Frank) Lin
In-Reply-To: <28760.1288650181@neuling.org>
On Tue, 2010-11-02 at 09:23 +1100, Michael Neuling wrote:
> +EXPORT_SYMBOL(switch_cop);
> +EXPORT_SYMBOL(use_cop);
> +EXPORT_SYMBOL(drop_cop);
>
> Please document how to use these.
Also, should these be _GPL ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] iSeries: Remove unused mf_getSrcHistory function.
From: Michael Ellerman @ 2010-11-02 0:20 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Stephen Rothwell, Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1011012218420.12889@swampdragon.chaosbits.net>
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
On Mon, 2010-11-01 at 22:20 +0100, Jesper Juhl wrote:
> Hi Stephen,
>
> On Tue, 2 Nov 2010, Stephen Rothwell wrote:
>
> > On Mon, 1 Nov 2010 21:06:23 +0100 (CET) Jesper Juhl <jj@chaosbits.net> wrote:
> > >
> > > Remove unused function 'mf_getSrcHistory' (that will never be used ever
> > > according to Stephen Rothwell).
> > >
> > > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> >
> > Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >
>
> Ok, so if you are the (unofficial) iSeries maintainer and you don't merge
> the patch somewhere that'll eventually go up-stream, but just ACK it
> (thank you for that btw), then where do I send it to get it merged?
Here. ie. linuxppc-dev.
But, while you're removing it you should remove the #if 0'ed callsite as
well, see mf_src_proc_show() in that file. :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 04/39] arch/powerpc: Update WARN uses
From: Michael Ellerman @ 2010-11-02 0:26 UTC (permalink / raw)
To: Joe Perches; +Cc: Paul Mackerras, Jiri Kosina, linuxppc-dev, linux-kernel
In-Reply-To: <1288622509.366.237.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]
On Mon, 2010-11-01 at 07:41 -0700, Joe Perches wrote:
> On Mon, 2010-11-01 at 22:02 +1100, Michael Ellerman wrote:
> > On Sat, 2010-10-30 at 14:08 -0700, Joe Perches wrote:
> > > Coalesce long formats.
> > > Align arguments.
> > > Add missing newlines.
> > >
> > > Signed-off-by: Joe Perches <joe@perches.com>
> > > ---
> > > arch/powerpc/kernel/hw_breakpoint.c | 4 ++--
> > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
> > > index 5ecd040..d7343a7 100644
> > > --- a/arch/powerpc/kernel/hw_breakpoint.c
> > > +++ b/arch/powerpc/kernel/hw_breakpoint.c
> > > @@ -270,8 +270,8 @@ int __kprobes hw_breakpoint_handler(struct die_args *args)
> > > * message to let the user know about it.
> > > */
> > > if (!stepped) {
> > > - WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
> > > - "0x%lx will be disabled.", info->address);
> > > + WARN(1, "Unable to handle hardware breakpoint. Breakpoint at 0x%lx will be disabled.\n",
> > > + info->address);
> >
> > That appears to have done nothing other than turn a short line into one
> > that is now > 80 columns.
>
> Added '\n'.
Right.
> The series was done for a few reasons:
>
> o to add missing newlines at the end of messages as was done here
> o to convert a couple of misuses of WARN(msg) to WARN(1, msg)
> o to remove KERN_ prefixes from WARN(test, KERN_<level> msg)
All fair enough.
> > Is that the latest fad?
>
> Pretty much. Format coalescing is generally preferred for grep.
Really? Grep doesn't work anyway because you have format specifiers, and
although you can try and guess them .. good luck, 0x%lx, or 0x%llx, or
%#lx or ..
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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