Re: [v4,17/21] powerpc/8xx: set PTE bit 22 off TLBmiss
Le 07/11/2014 04:37, Scott Wood a écrit : On Fri, Sep 19, 2014 at 10:36:09AM +0200, LEROY Christophe wrote: No need to re-set this bit at each TLB miss. Let's set it in the PTE. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr --- Changes in v2: - None Changes in v3: - Removed PPC405 related macro from PPC8xx specific code - PTE_NONE_MASK doesn't need PAGE_ACCESSED in Linux 2.6 Changes in v4: - None arch/powerpc/include/asm/pgtable-ppc32.h | 20 arch/powerpc/include/asm/pte-8xx.h | 7 +-- arch/powerpc/kernel/head_8xx.S | 10 ++ 3 files changed, 27 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h index 47edde8..35a9b44 100644 --- a/arch/powerpc/include/asm/pgtable-ppc32.h +++ b/arch/powerpc/include/asm/pgtable-ppc32.h @@ -172,6 +172,25 @@ static inline unsigned long pte_update(pte_t *p, #ifdef PTE_ATOMIC_UPDATES unsigned long old, tmp; +#ifdef CONFIG_PPC_8xx + unsigned long tmp2; + + __asm__ __volatile__(\ +1: lwarx %0,0,%4\n\ + andc%1,%0,%5\n\ + or %1,%1,%6\n\ + /* 0x200 == Extended encoding, bit 22 */ \ + /* Bit 22 has to be 1 if neither _PAGE_USER nor _PAGE_RW are set */ \ + rlwimi %1,%1,32-2,0x200\n /* get _PAGE_USER */ \ + rlwinm %3,%1,32-1,0x200\n /* get _PAGE_RW */ \ + or %1,%3,%1\n\ + xori%1,%1,0x200\n + stwcx. %1,0,%4\n\ + bne-1b Why do you need this... diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h index d44826e..daa4616 100644 --- a/arch/powerpc/include/asm/pte-8xx.h +++ b/arch/powerpc/include/asm/pte-8xx.h @@ -48,19 +48,22 @@ */ #define _PAGE_RW 0x0400 /* lsb PP bits, inverted in HW */ #define _PAGE_USER0x0800 /* msb PP bits */ +/* set when neither _PAGE_USER nor _PAGE_RW are set */ +#define _PAGE_KNLRO0x0200 #define _PMD_PRESENT 0x0001 #define _PMD_BAD 0x0ff0 #define _PMD_PAGE_MASK0x000c #define _PMD_PAGE_8M 0x000c -#define _PTE_NONE_MASK _PAGE_ACCESSED +#define _PTE_NONE_MASK _PAGE_KNLRO /* Until my rework is finished, 8xx still needs atomic PTE updates */ #define PTE_ATOMIC_UPDATES1 /* We need to add _PAGE_SHARED to kernel pages */ -#define _PAGE_KERNEL_RO(_PAGE_SHARED) +#define _PAGE_KERNEL_RO(_PAGE_SHARED | _PAGE_KNLRO) +#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_KNLRO) #define _PAGE_KERNEL_RW (_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE) ...if 0x200 is already being set in the PTE here? If I understand well the way it works, those defines are used for setting the PTE the first time. Then, pte_update() is used to modify the pte settings on an existing pte 0x200 must be set when and only when the page is a RO kernel page. If later on pte_update() is called for instance to set the page to RW, the 0x200 has to be removed. Same, if pte_update() is called to remove _PAGE_RW (ptep_set_wrprotect() does this), 0x200 must be set back. Christophe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
Hello Scott, On 11/07/2014 01:34 AM, Scott Wood wrote: On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote: Hello Scott, On 11/06/2014 03:49 PM, Scott Wood wrote: On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link +to the respective BMan instance + +- fsl,bman + Usage: Required + Value type: prop-encoded-array + Description:List of phandle and DCP index pairs, to the BMan instance + to which this device is connected via the DCP Does software need the DCP index (though for QMan there do seem to be a few registers associated with each DCP)? Where can I find that info in the manual? The DCP index helps describe the topology of the devices connected to the B/QMan. One might be tempted to use some address to reference said DCP, unfortunately the pertinent registers/bits for said DCP(s) are not into a compact region. Look at the CCSR memory map for B/QMan In the QMan case things are marginally better. For each hardware portal there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers (configuration, performance monitoring and debugging). However, still registers and bits spread here and there In the BMan case things are a bit worse as the registers names are less friendly and still spread around Do you need specific names/offsets? My question about the manual wasn't rhetorical -- I tried to find this information and couldn't. I get that. As I said, the registers/bits are spread around in the CCSR space of each block and not named excessively friendly. As such I hinted for some search patterns to make it easier to find them. In order to progress the review I'm willing to prepare a list. Just let me know Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Fri, 2014-11-07 at 02:14 -0600, Emil Medve wrote: Hello Scott, On 11/07/2014 01:34 AM, Scott Wood wrote: On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote: Hello Scott, On 11/06/2014 03:49 PM, Scott Wood wrote: On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link +to the respective BMan instance + +- fsl,bman +Usage: Required +Value type: prop-encoded-array +Description:List of phandle and DCP index pairs, to the BMan instance +to which this device is connected via the DCP Does software need the DCP index (though for QMan there do seem to be a few registers associated with each DCP)? Where can I find that info in the manual? The DCP index helps describe the topology of the devices connected to the B/QMan. One might be tempted to use some address to reference said DCP, unfortunately the pertinent registers/bits for said DCP(s) are not into a compact region. Look at the CCSR memory map for B/QMan In the QMan case things are marginally better. For each hardware portal there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers (configuration, performance monitoring and debugging). However, still registers and bits spread here and there In the BMan case things are a bit worse as the registers names are less friendly and still spread around Do you need specific names/offsets? My question about the manual wasn't rhetorical -- I tried to find this information and couldn't. I get that. As I said, the registers/bits are spread around in the CCSR space of each block and not named excessively friendly. As such I hinted for some search patterns to make it easier to find them. In order to progress the review I'm willing to prepare a list. Just let me know Could you point me to the section of the manual where this information is -- friendly or otherwise? I saw the QMan direct connect portal registers. I didn't see how to tell which i in DCPi_xxx goes with which device. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/8xx: Remove Kconfig symbol FADS
On Thu, 2014-11-06 at 21:50 -0600, Scott Wood wrote: On Wed, Sep 24, 2014 at 10:06:19AM +0200, Paul Bolle wrote: Another cleanup might be to remove MPC8XXFADS (or FADS) from the 8xx Machine Type choice. Is there any reason left to pick FADS as a machine type? Nothing references MPC8XXFADS, so yes, it can be removed. I'll try to look into this. For the (verbose) reasons below I'll do that in a separate patch, if I ever get that far. What follows is mostly a note to self. MPC8XXFADS is indeed not referenced anywhere. But it's one of the entries in the 8xx Machine Type choice. And it's common for choice blocks the have a none of the above entry. Ie, an entry that allows to configure nothing. There's a chance MPC8XXFADS is currently used for that role. (This is easier to determine for people that - unlike me - know what all the symbols in this choice mean. To me they 're basically random strings.) Actually, there's an obscure optional Kconfig keyword that appears to be added to take care of this use case. It's currently used exactly twice in the tree, in smaller architectures: once in arch/avr32/ and once in arch/sh/. This implies this optional keyword is used very little. I'll have to look carefully to see whether it works as advertised. Paul Bolle ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
Hello Scott, On 11/07/2014 02:19 AM, Scott Wood wrote: On Fri, 2014-11-07 at 02:14 -0600, Emil Medve wrote: Hello Scott, On 11/07/2014 01:34 AM, Scott Wood wrote: On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote: Hello Scott, On 11/06/2014 03:49 PM, Scott Wood wrote: On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link +to the respective BMan instance + +- fsl,bman +Usage: Required +Value type: prop-encoded-array +Description:List of phandle and DCP index pairs, to the BMan instance +to which this device is connected via the DCP Does software need the DCP index (though for QMan there do seem to be a few registers associated with each DCP)? Where can I find that info in the manual? The DCP index helps describe the topology of the devices connected to the B/QMan. One might be tempted to use some address to reference said DCP, unfortunately the pertinent registers/bits for said DCP(s) are not into a compact region. Look at the CCSR memory map for B/QMan In the QMan case things are marginally better. For each hardware portal there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers (configuration, performance monitoring and debugging). However, still registers and bits spread here and there In the BMan case things are a bit worse as the registers names are less friendly and still spread around Do you need specific names/offsets? My question about the manual wasn't rhetorical -- I tried to find this information and couldn't. I get that. As I said, the registers/bits are spread around in the CCSR space of each block and not named excessively friendly. As such I hinted for some search patterns to make it easier to find them. In order to progress the review I'm willing to prepare a list. Just let me know Could you point me to the section of the manual where this information is -- friendly or otherwise? I saw the QMan direct connect portal registers. I didn't see how to tell which i in DCPi_xxx goes with which device. For QMan look into section '6.3.10 Direct Connect Portals (DCPs)'. The BMan DCP assignment is the same Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Fri, 2014-11-07 at 03:38 -0600, Emil Medve wrote: Hello Scott, On 11/07/2014 02:19 AM, Scott Wood wrote: On Fri, 2014-11-07 at 02:14 -0600, Emil Medve wrote: Hello Scott, On 11/07/2014 01:34 AM, Scott Wood wrote: On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote: Hello Scott, On 11/06/2014 03:49 PM, Scott Wood wrote: On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link +to the respective BMan instance + +- fsl,bman + Usage: Required + Value type: prop-encoded-array + Description:List of phandle and DCP index pairs, to the BMan instance + to which this device is connected via the DCP Does software need the DCP index (though for QMan there do seem to be a few registers associated with each DCP)? Where can I find that info in the manual? The DCP index helps describe the topology of the devices connected to the B/QMan. One might be tempted to use some address to reference said DCP, unfortunately the pertinent registers/bits for said DCP(s) are not into a compact region. Look at the CCSR memory map for B/QMan In the QMan case things are marginally better. For each hardware portal there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers (configuration, performance monitoring and debugging). However, still registers and bits spread here and there In the BMan case things are a bit worse as the registers names are less friendly and still spread around Do you need specific names/offsets? My question about the manual wasn't rhetorical -- I tried to find this information and couldn't. I get that. As I said, the registers/bits are spread around in the CCSR space of each block and not named excessively friendly. As such I hinted for some search patterns to make it easier to find them. In order to progress the review I'm willing to prepare a list. Just let me know Could you point me to the section of the manual where this information is -- friendly or otherwise? I saw the QMan direct connect portal registers. I didn't see how to tell which i in DCPi_xxx goes with which device. For QMan look into section '6.3.10 Direct Connect Portals (DCPs)'. The BMan DCP assignment is the same Thanks, I'm not sure how I missed that. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] PPC: bpf_jit_comp: add SKF_AD_HATYPE instruction
From: Denis Kirjanov k...@linux-powerpc.org Date: Thu, 6 Nov 2014 09:02:35 +0300 Add BPF extension SKF_AD_HATYPE to ppc JIT to check the hw type of the interface JIT off: [ 69.106783] test_bpf: #20 LD_HATYPE 48 48 PASS JIT on: [ 64.721757] test_bpf: #20 LD_HATYPE 7 6 PASS CC: Alexei Starovoitovalexei.starovoi...@gmail.com CC: Daniel Borkmanndbork...@redhat.com CC: Philippe Bergheaudfe...@linux.vnet.ibm.com Signed-off-by: Denis Kirjanov k...@linux-powerpc.org Can I get some reviews please? Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v4,17/21] powerpc/8xx: set PTE bit 22 off TLBmiss
On Fri, 2014-11-07 at 09:00 +0100, leroy christophe wrote: Le 07/11/2014 04:37, Scott Wood a écrit : On Fri, Sep 19, 2014 at 10:36:09AM +0200, LEROY Christophe wrote: No need to re-set this bit at each TLB miss. Let's set it in the PTE. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr --- Changes in v2: - None Changes in v3: - Removed PPC405 related macro from PPC8xx specific code - PTE_NONE_MASK doesn't need PAGE_ACCESSED in Linux 2.6 Changes in v4: - None arch/powerpc/include/asm/pgtable-ppc32.h | 20 arch/powerpc/include/asm/pte-8xx.h | 7 +-- arch/powerpc/kernel/head_8xx.S | 10 ++ 3 files changed, 27 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h index 47edde8..35a9b44 100644 --- a/arch/powerpc/include/asm/pgtable-ppc32.h +++ b/arch/powerpc/include/asm/pgtable-ppc32.h @@ -172,6 +172,25 @@ static inline unsigned long pte_update(pte_t *p, #ifdef PTE_ATOMIC_UPDATES unsigned long old, tmp; +#ifdef CONFIG_PPC_8xx + unsigned long tmp2; + + __asm__ __volatile__(\ +1:lwarx %0,0,%4\n\ + andc%1,%0,%5\n\ + or %1,%1,%6\n\ + /* 0x200 == Extended encoding, bit 22 */ \ + /* Bit 22 has to be 1 if neither _PAGE_USER nor _PAGE_RW are set */ \ + rlwimi %1,%1,32-2,0x200\n /* get _PAGE_USER */ \ + rlwinm %3,%1,32-1,0x200\n /* get _PAGE_RW */ \ + or %1,%3,%1\n\ + xori%1,%1,0x200\n + stwcx. %1,0,%4\n\ + bne-1b Why do you need this... diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h index d44826e..daa4616 100644 --- a/arch/powerpc/include/asm/pte-8xx.h +++ b/arch/powerpc/include/asm/pte-8xx.h @@ -48,19 +48,22 @@ */ #define _PAGE_RW 0x0400 /* lsb PP bits, inverted in HW */ #define _PAGE_USER 0x0800 /* msb PP bits */ +/* set when neither _PAGE_USER nor _PAGE_RW are set */ +#define _PAGE_KNLRO 0x0200 #define _PMD_PRESENT 0x0001 #define _PMD_BAD 0x0ff0 #define _PMD_PAGE_MASK 0x000c #define _PMD_PAGE_8M 0x000c -#define _PTE_NONE_MASK _PAGE_ACCESSED +#define _PTE_NONE_MASK _PAGE_KNLRO /* Until my rework is finished, 8xx still needs atomic PTE updates */ #define PTE_ATOMIC_UPDATES 1 /* We need to add _PAGE_SHARED to kernel pages */ -#define _PAGE_KERNEL_RO (_PAGE_SHARED) +#define _PAGE_KERNEL_RO (_PAGE_SHARED | _PAGE_KNLRO) +#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_KNLRO) #define _PAGE_KERNEL_RW (_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE) ...if 0x200 is already being set in the PTE here? If I understand well the way it works, those defines are used for setting the PTE the first time. Then, pte_update() is used to modify the pte settings on an existing pte 0x200 must be set when and only when the page is a RO kernel page. If later on pte_update() is called for instance to set the page to RW, the 0x200 has to be removed. Same, if pte_update() is called to remove _PAGE_RW (ptep_set_wrprotect() does this), 0x200 must be set back. OK, so the _PAGE_KERNEL_RO(X) stuff is because initially setting the PTE doesn't go through pte_update(). I'll apply this, though it'd be cleaner to just have 8xx versions of the relevant PTE accessor functions to maintain the PTE the way the hardware wants (this would also eliminate the _PAGE_RW inversion that's still in the TLB miss handler). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/8xx: Remove Kconfig symbol FADS
On Fri, 2014-11-07 at 09:48 +0100, Paul Bolle wrote: On Thu, 2014-11-06 at 21:50 -0600, Scott Wood wrote: On Wed, Sep 24, 2014 at 10:06:19AM +0200, Paul Bolle wrote: Another cleanup might be to remove MPC8XXFADS (or FADS) from the 8xx Machine Type choice. Is there any reason left to pick FADS as a machine type? Nothing references MPC8XXFADS, so yes, it can be removed. I'll try to look into this. For the (verbose) reasons below I'll do that in a separate patch, if I ever get that far. What follows is mostly a note to self. Yes, make it a separate patch -- I've already got this patch queued up. MPC8XXFADS is indeed not referenced anywhere. But it's one of the entries in the 8xx Machine Type choice. And it's common for choice blocks the have a none of the above entry. Ie, an entry that allows to configure nothing. There's a chance MPC8XXFADS is currently used for that role. (This is easier to determine for people that - unlike me - know what all the symbols in this choice mean. To me they 're basically random strings.) It's not a none of the above option. It's a board type that was supported in arch/ppc, and only some remnants made it over to arch/powerpc. If you don't pick a machine type that results in a define_machine() struct (with a probe function that matches the device tree), the kernel will not boot. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
