Re: [PATCH -V7 18/18] powerpc: Update tlbie/tlbiel as per ISA doc
On Mon, Apr 29, 2013 at 01:07:39AM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Encode the actual page correctly in tlbie/tlbiel. This make sure we handle
multiple page size segment correctly.
As mentioned in previous comments, this commit message needs to give
much more detail about what precisely the existing implementation is
doing wrong.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/mm/hash_native_64.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hash_native_64.c
b/arch/powerpc/mm/hash_native_64.c
index bb920ee..6a2aead 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -61,7 +61,10 @@ static inline void __tlbie(unsigned long vpn, int psize,
int apsize, int ssize)
switch (psize) {
case MMU_PAGE_4K:
+ /* clear out bits after (52) [052.63] */
+ va = ~((1ul (64 - 52)) - 1);
va |= ssize 8;
+ va |= mmu_psize_defs[apsize].sllp 6;
asm volatile(ASM_FTR_IFCLR(tlbie %0,0, PPC_TLBIE(%1,%0), %2)
: : r (va), r(0), i (CPU_FTR_ARCH_206)
: memory);
@@ -69,9 +72,20 @@ static inline void __tlbie(unsigned long vpn, int psize,
int apsize, int ssize)
default:
/* We need 14 to 14 + i bits of va */
penc = mmu_psize_defs[psize].penc[apsize];
- va = ~((1ul mmu_psize_defs[psize].shift) - 1);
+ va = ~((1ul mmu_psize_defs[apsize].shift) - 1);
va |= penc 12;
va |= ssize 8;
+ /* Add AVAL part */
+ if (psize != apsize) {
+ /*
+ * MPSS, 64K base page size and 16MB parge page size
+ * We don't need all the bits, but rest of the bits
+ * must be ignored by the processor.
+ * vpn cover upto 65 bits of va. (0...65) and we need
+ * 58..64 bits of va.
I can't understand what this comment is saying. Why do we need to do
something different in the psize != apsize case?
+ */
+ va |= (vpn 0xfe);
+ }
va |= 1; /* L */
asm volatile(ASM_FTR_IFCLR(tlbie %0,1, PPC_TLBIE(%1,%0), %2)
: : r (va), r(0), i (CPU_FTR_ARCH_206)
@@ -96,16 +110,30 @@ static inline void __tlbiel(unsigned long vpn, int
psize, int apsize, int ssize)
switch (psize) {
case MMU_PAGE_4K:
+ /* clear out bits after(52) [052.63] */
+ va = ~((1ul (64 - 52)) - 1);
va |= ssize 8;
+ va |= mmu_psize_defs[apsize].sllp 6;
asm volatile(.long 0x7c000224 | (%0 11) | (0 21)
: : r(va) : memory);
break;
default:
/* We need 14 to 14 + i bits of va */
penc = mmu_psize_defs[psize].penc[apsize];
- va = ~((1ul mmu_psize_defs[psize].shift) - 1);
+ va = ~((1ul mmu_psize_defs[apsize].shift) - 1);
va |= penc 12;
va |= ssize 8;
+ /* Add AVAL part */
+ if (psize != apsize) {
+ /*
+ * MPSS, 64K base page size and 16MB parge page size
+ * We don't need all the bits, but rest of the bits
+ * must be ignored by the processor.
+ * vpn cover upto 65 bits of va. (0...65) and we need
+ * 58..64 bits of va.
+ */
+ va |= (vpn 0xfe);
+ }
va |= 1; /* L */
asm volatile(.long 0x7c000224 | (%0 11) | (1 21)
: : r(va) : memory);
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
Apologies for resurrecting a very old thread, but...
On 05/30/2012 02:14 PM, Anthony Foiani wrote:
Maybe someone who knows devtree really well could crank that out in a
few minutes... but I'm not that person. :)
Well, I wasn't last year, but this year I decided that I didn't care.
Took me about an hour, not a minute, but...
Having been bitten by this config symbol disappearing one more time,
please find attached my attempt at using information out of the device
tree to enable this hack.
Patch is against 3.4.36 or so; hopefully upstream hasn't diverged very much.
Tested by me, so feel free to add that tag if required.
Thanks,
Anthony Foiani
From c0a85758a669b430c0a6af825e71d18a54ef88d0 Mon Sep 17 00:00:00 2001
From: Anthony Foiani anthony.foi...@gmail.com
Date: Mon, 29 Apr 2013 23:44:14 -0600
Subject: [PATCH] sata: fsl: allow device tree to limit sata speed.
There used to be an orphan config symbol (CONFIG_MPC8315_DS) that
would artificially limit SATA speed to generation 1 (1.5Gbps).
Since that config symbol got lost whenever any sort of configuration
was done, we instead extract the limitation from the device tree.
Signed-off-by: Anthony Foiani anthony.foi...@gmail.com
---
.../devicetree/bindings/powerpc/fsl/board.txt | 23 +++
drivers/ata/sata_fsl.c | 44 ++
2 files changed, 59 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 380914e..6a30398 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -67,3 +67,26 @@ Example:
gpio-controller;
};
};
+
+* Maximum SATA Generation workaround
+
+Some boards advertise SATA speeds that they cannot actually achieve.
+Previously, this was dealt with via the orphaned config symbol
+CONFIG_MPC8315_DS. We now have a device tree property
+fsl,sata-max-gen to control this. It should live within the sata
+block.
+
+Example:
+
+ sata@18000 {
+ compatible = fsl,mpc8315-sata, fsl,pq-sata;
+ reg = 0x18000 0x1000;
+ cell-index = 1;
+ interrupts = 44 0x8;
+ interrupt-parent = ipic;
+ fsl,sata-max-gen = 1;
+ };
+
+By default, there is no limitation; if a value is given, it indicates
+the maximum generation that should be negotiated. Gen 1 is 1.5Gbps,
+Gen 2 is 3.0Gbps.
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index d6577b9..6d3ec47 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -274,6 +274,17 @@ struct sata_fsl_port_priv {
};
/*
+ * speed negotiation.
+ */
+
+enum {
+ SCR_SPEED_NEG_MASK = 0xf0,
+ SCR_SPEED_NEG_UNLIMITED = 0x00,
+ SCR_SPEED_NEG_GEN_1 = 0x10, /* 1.5Gbps max */
+ SCR_SPEED_NEG_GEN_2 = 0x20 /* 3.0Gbps max */
+};
+
+/*
* ata_port-host_set private data
*/
struct sata_fsl_host_priv {
@@ -282,6 +293,7 @@ struct sata_fsl_host_priv {
void __iomem *csr_base;
int irq;
int data_snoop;
+ u32 speed_neg;
struct device_attribute intr_coalescing;
};
@@ -726,19 +738,23 @@ static int sata_fsl_port_start(struct ata_port *ap)
VPRINTK(HControl = 0x%x\n, ioread32(hcr_base + HCONTROL));
VPRINTK(CHBA = 0x%x\n, ioread32(hcr_base + CHBA));
-#ifdef CONFIG_MPC8315_DS
/*
* Workaround for 8315DS board 3gbps link-up issue,
* currently limit SATA port to GEN1 speed
*/
- sata_fsl_scr_read(ap-link, SCR_CONTROL, temp);
- temp = ~(0xF 4);
- temp |= (0x1 4);
- sata_fsl_scr_write(ap-link, SCR_CONTROL, temp);
+ if ( host_priv-speed_neg != SCR_SPEED_NEG_UNLIMITED )
+ {
- sata_fsl_scr_read(ap-link, SCR_CONTROL, temp);
- dev_warn(dev, scr_control, speed limited to %x\n, temp);
-#endif
+ u32 orig;
+ sata_fsl_scr_read(ap-link, SCR_CONTROL, orig);
+ temp = ( ( orig ~SCR_SPEED_NEG_MASK ) |
+ ( host_priv-speed_neg SCR_SPEED_NEG_MASK ) );
+ sata_fsl_scr_write(ap-link, SCR_CONTROL, temp);
+
+ sata_fsl_scr_read(ap-link, SCR_CONTROL, temp);
+ dev_warn(dev, speed limited, scr_control 0x%x - 0x%x\n,
+ orig, temp);
+ }
return 0;
}
@@ -1437,6 +1453,18 @@ static int sata_fsl_probe(struct platform_device *ofdev)
else
host_priv-data_snoop = DATA_SNOOP_ENABLE_V1;
+ if (!of_property_read_u32(ofdev-dev.of_node, fsl,sata-max-gen,
+ temp))
+ {
+ switch (temp)
+ {
+ case 1: host_priv-speed_neg = SCR_SPEED_NEG_GEN_1; break;
+ case 2: host_priv-speed_neg = SCR_SPEED_NEG_GEN_2; break;
+ }
+ dev_warn(ofdev-dev, speed limit set to gen %u (0x%x)\n,
+ temp, host_priv-speed_neg);
+ }
+
/* allocate host structure */
host = ata_host_alloc_pinfo(ofdev-dev, ppi, SATA_FSL_MAX_PORTS);
if (!host) {
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix interrupt range check on debug exception
We do not want to take single step and branch-taken debug exception in kernel exception code. But the address range check was not covering all kernel exception handlers address range. With this patch we defined the interrupt_end label which defines the end on kernel exception code. So now we check interrupt_base to interrupt_end range for not handling debug exception in kernel exception entry. Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com --- arch/powerpc/kernel/head_44x.S |2 ++ arch/powerpc/kernel/head_booke.h | 16 arch/powerpc/kernel/head_fsl_booke.S |2 ++ 3 files changed, 12 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S index 7a2e5e4..97e2671 100644 --- a/arch/powerpc/kernel/head_44x.S +++ b/arch/powerpc/kernel/head_44x.S @@ -769,6 +769,8 @@ finish_tlb_load_47x: */ DEBUG_CRIT_EXCEPTION +interrupt_end: + /* * Global functions */ diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h index 5f051ee..df564e9 100644 --- a/arch/powerpc/kernel/head_booke.h +++ b/arch/powerpc/kernel/head_booke.h @@ -286,13 +286,13 @@ label: andis. r10,r10,(DBSR_IC|DBSR_BT)@h; \ beq+2f; \ \ - lis r10,KERNELBASE@h; /* check if exception in vectors */ \ - ori r10,r10,KERNELBASE@l; \ + lis r10,interrupt_base@h; /* check if exception in vectors */ \ + ori r10,r10,interrupt_base@l; \ cmplw r12,r10; \ blt+2f; /* addr below exception vectors */\ \ - lis r10,DebugDebug@h; \ - ori r10,r10,DebugDebug@l; \ + lis r10,interrupt_end@h; \ + ori r10,r10,interrupt_end@l; \ cmplw r12,r10; \ bgt+2f; /* addr above exception vectors */\ \ @@ -339,13 +339,13 @@ label: andis. r10,r10,(DBSR_IC|DBSR_BT)@h; \ beq+2f; \ \ - lis r10,KERNELBASE@h; /* check if exception in vectors */ \ - ori r10,r10,KERNELBASE@l; \ + lis r10,interrupt_base@h; /* check if exception in vectors */ \ + ori r10,r10,interrupt_base@l; \ cmplw r12,r10; \ blt+2f; /* addr below exception vectors */\ \ - lis r10,DebugCrit@h; \ - ori r10,r10,DebugCrit@l; \ + lis r10,interrupt_end@h; \ + ori r10,r10,interrupt_end@l; \ cmplw r12,r10; \ bgt+2f; /* addr above exception vectors */\ \ diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 6f62a73..d10a7ca 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -605,6 +605,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV) /* Embedded Hypervisor Privilege */ EXCEPTION(0, HV_PRIV, Ehvpriv, unknown_exception, EXC_XFER_EE) +interrupt_end: + /* * Local functions */ -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2 v15] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
Hi Joerg,
Would you take this patchset for 3.10 merge?
Regards
Varun
-Original Message-
From: Sethi Varun-B16395
Sent: Wednesday, April 24, 2013 5:06 PM
To: j...@8bytes.org; io...@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org;
ga...@kernel.crashing.org; b...@kernel.crashing.org; Yoder Stuart-B08248;
Wood Scott-B07421
Cc: Sethi Varun-B16395
Subject: [PATCH 1/2 v15] iommu/fsl: Add additional iommu attributes
required by the PAMU driver.
Added the following domain attributes for the FSL PAMU driver:
1. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
2. Added an attribute for enabling/disabling DMA to a particular
memory window.
3. Added domain attribute to check for PAMUV1 specific constraints.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
v15 changes:
- Moved fsl_pamu_stash.h under arch/powerpc/include/asm.
v14 changes:
- Add FSL prefix to PAMU attributes.
v13 changes:
- created a new file include/linux/fsl_pamu_stash.h for stash attributes.
v12 changes:
- Moved PAMU specifc stash ids and structures to PAMU header file.
- no change in v11.
- no change in v10.
arch/powerpc/include/asm/fsl_pamu_stash.h | 39
+
include/linux/iommu.h | 16
2 files changed, 55 insertions(+), 0 deletions(-) create mode 100644
arch/powerpc/include/asm/fsl_pamu_stash.h
diff --git a/arch/powerpc/include/asm/fsl_pamu_stash.h
b/arch/powerpc/include/asm/fsl_pamu_stash.h
new file mode 100644
index 000..caa1b21
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_pamu_stash.h
@@ -0,0 +1,39 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ */
+
+#ifndef __FSL_PAMU_STASH_H
+#define __FSL_PAMU_STASH_H
+
+/* cache stash targets */
+enum pamu_stash_target {
+ PAMU_ATTR_CACHE_L1 = 1,
+ PAMU_ATTR_CACHE_L2,
+ PAMU_ATTR_CACHE_L3,
+};
+
+/*
+ * This attribute allows configuring stashig specific parameters
+ * in the PAMU hardware.
+ */
+
+struct pamu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
+};
+
+#endif /* __FSL_PAMU_STASH_H */
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
2727810..313d17a 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -57,10 +57,26 @@ struct iommu_domain {
#define IOMMU_CAP_CACHE_COHERENCY0x1
#define IOMMU_CAP_INTR_REMAP 0x2 /* isolates device intrs */
+/*
+ * Following constraints are specifc to FSL_PAMUV1:
+ * -aperture must be power of 2, and naturally aligned
+ * -number of windows must be power of 2, and address space size
+ * of each window is determined by aperture size / # of windows
+ * -the actual size of the mapped region of a window must be power
+ * of 2 starting with 4KB and physical address must be naturally
+ * aligned.
+ * DOMAIN_ATTR_FSL_PAMUV1 corresponds to the above mentioned contraints.
+ * The caller can invoke iommu_domain_get_attr to check if the
+underlying
+ * iommu implementation supports these constraints.
+ */
+
enum iommu_attr {
DOMAIN_ATTR_GEOMETRY,
DOMAIN_ATTR_PAGING,
DOMAIN_ATTR_WINDOWS,
+ DOMAIN_ATTR_FSL_PAMU_STASH,
+ DOMAIN_ATTR_FSL_PAMU_ENABLE,
+ DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_MAX,
};
--
1.7.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V7 18/18] powerpc: Update tlbie/tlbiel as per ISA doc
David Gibson d...@au1.ibm.com writes:
On Mon, Apr 29, 2013 at 01:07:39AM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Encode the actual page correctly in tlbie/tlbiel. This make sure we handle
multiple page size segment correctly.
As mentioned in previous comments, this commit message needs to give
much more detail about what precisely the existing implementation is
doing wrong.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/mm/hash_native_64.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hash_native_64.c
b/arch/powerpc/mm/hash_native_64.c
index bb920ee..6a2aead 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -61,7 +61,10 @@ static inline void __tlbie(unsigned long vpn, int psize,
int apsize, int ssize)
switch (psize) {
case MMU_PAGE_4K:
+/* clear out bits after (52) [052.63] */
+va = ~((1ul (64 - 52)) - 1);
va |= ssize 8;
+va |= mmu_psize_defs[apsize].sllp 6;
asm volatile(ASM_FTR_IFCLR(tlbie %0,0, PPC_TLBIE(%1,%0), %2)
: : r (va), r(0), i (CPU_FTR_ARCH_206)
: memory);
@@ -69,9 +72,20 @@ static inline void __tlbie(unsigned long vpn, int psize,
int apsize, int ssize)
default:
/* We need 14 to 14 + i bits of va */
penc = mmu_psize_defs[psize].penc[apsize];
-va = ~((1ul mmu_psize_defs[psize].shift) - 1);
+va = ~((1ul mmu_psize_defs[apsize].shift) - 1);
va |= penc 12;
va |= ssize 8;
+/* Add AVAL part */
+if (psize != apsize) {
+/*
+ * MPSS, 64K base page size and 16MB parge page size
+ * We don't need all the bits, but rest of the bits
+ * must be ignored by the processor.
+ * vpn cover upto 65 bits of va. (0...65) and we need
+ * 58..64 bits of va.
I can't understand what this comment is saying. Why do we need to do
something different in the psize != apsize case?
+ */
+va |= (vpn 0xfe);
+}
That is as per ISA doc. It says if base page size == actual page size,
(RB)56:62 must be zeros, which must be ignored by the processor.
Otherwise it should be filled with the selected bits of VA as explained above.
We only support MPSS with base page size = 64K and actual page size = 16MB.
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
On 04/30/2013 01:41:49 AM, Anthony Foiani wrote:
Apologies for resurrecting a very old thread, but...
On 05/30/2012 02:14 PM, Anthony Foiani wrote:
Maybe someone who knows devtree really well could crank that out in a
few minutes... but I'm not that person. :)
Well, I wasn't last year, but this year I decided that I didn't
care. Took me about an hour, not a minute, but...
Having been bitten by this config symbol disappearing one more time,
please find attached my attempt at using information out of the
device tree to enable this hack.
Patch is against 3.4.36 or so; hopefully upstream hasn't diverged
very much.
Tested by me, so feel free to add that tag if required.
Thanks,
Anthony Foiani
--quoted attachment
0001-sata-fsl-allow-device-tree-to-limit-sata-speed.patch--
From c0a85758a669b430c0a6af825e71d18a54ef88d0 Mon Sep 17 00:00:00
2001
From: Anthony Foiani anthony.foi...@gmail.com
Date: Mon, 29 Apr 2013 23:44:14 -0600
Subject: [PATCH] sata: fsl: allow device tree to limit sata speed.
There used to be an orphan config symbol (CONFIG_MPC8315_DS) that
would artificially limit SATA speed to generation 1 (1.5Gbps).
Since that config symbol got lost whenever any sort of configuration
was done, we instead extract the limitation from the device tree.
Signed-off-by: Anthony Foiani anthony.foi...@gmail.com
---
.../devicetree/bindings/powerpc/fsl/board.txt | 23 +++
drivers/ata/sata_fsl.c | 44
++
2 files changed, 59 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 380914e..6a30398 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -67,3 +67,26 @@ Example:
gpio-controller;
};
};
+
+* Maximum SATA Generation workaround
+
+Some boards advertise SATA speeds that they cannot actually achieve.
+Previously, this was dealt with via the orphaned config symbol
+CONFIG_MPC8315_DS. We now have a device tree property
+fsl,sata-max-gen to control this. It should live within the sata
+block.
+
+Example:
+
+ sata@18000 {
+ compatible = fsl,mpc8315-sata, fsl,pq-sata;
+ reg = 0x18000 0x1000;
+ cell-index = 1;
+ interrupts = 44 0x8;
+ interrupt-parent = ipic;
+ fsl,sata-max-gen = 1;
+ };
+
This might be OK for a new board, but adding it now means that people
using existing device trees won't get the workaround. It might be
better to just put the knowledge in platform code.
+By default, there is no limitation; if a value is given, it indicates
+the maximum generation that should be negotiated. Gen 1 is
1.5Gbps,
+Gen 2 is 3.0Gbps.
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index d6577b9..6d3ec47 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -274,6 +274,17 @@ struct sata_fsl_port_priv {
};
/*
+ * speed negotiation.
+ */
+
+enum {
+ SCR_SPEED_NEG_MASK = 0xf0,
+ SCR_SPEED_NEG_UNLIMITED = 0x00,
+ SCR_SPEED_NEG_GEN_1 = 0x10, /* 1.5Gbps max */
+ SCR_SPEED_NEG_GEN_2 = 0x20 /* 3.0Gbps max */
+};
+
+/*
* ata_port-host_set private data
*/
struct sata_fsl_host_priv {
@@ -282,6 +293,7 @@ struct sata_fsl_host_priv {
void __iomem *csr_base;
int irq;
int data_snoop;
+ u32 speed_neg;
struct device_attribute intr_coalescing;
};
@@ -726,19 +738,23 @@ static int sata_fsl_port_start(struct ata_port
*ap)
VPRINTK(HControl = 0x%x\n, ioread32(hcr_base + HCONTROL));
VPRINTK(CHBA = 0x%x\n, ioread32(hcr_base + CHBA));
-#ifdef CONFIG_MPC8315_DS
/*
* Workaround for 8315DS board 3gbps link-up issue,
* currently limit SATA port to GEN1 speed
*/
- sata_fsl_scr_read(ap-link, SCR_CONTROL, temp);
- temp = ~(0xF 4);
- temp |= (0x1 4);
- sata_fsl_scr_write(ap-link, SCR_CONTROL, temp);
+ if ( host_priv-speed_neg != SCR_SPEED_NEG_UNLIMITED )
+ {
- sata_fsl_scr_read(ap-link, SCR_CONTROL, temp);
- dev_warn(dev, scr_control, speed limited to %x\n, temp);
-#endif
+ u32 orig;
+ sata_fsl_scr_read(ap-link, SCR_CONTROL, orig);
+ temp = ( ( orig ~SCR_SPEED_NEG_MASK )
|
+ ( host_priv-speed_neg SCR_SPEED_NEG_MASK )
);
+ sata_fsl_scr_write(ap-link, SCR_CONTROL, temp);
+
+ sata_fsl_scr_read(ap-link, SCR_CONTROL, temp);
+ dev_warn(dev, speed limited, scr_control 0x%x -
0x%x\n,
+orig, temp);
+ }
return 0;
}
@@ -1437,6 +1453,18 @@ static int sata_fsl_probe(struct
platform_device *ofdev)
else
flush_icache_range on AMCC 44x targets
Hi, i was reading trough arch/powerpc/kernel/misc32.S looking at the icbi and iccci instructions, from whats on print in http://s.eeweb.com/members/kvks_kumar/answers/1356585717-PPC440_UM2013.pdf(page 272) iccci should be used once in the power-on / reset routine, and as far as flush_icache_range goes presumably before icbi is called? So should not flush_icache_range go #ifdef CONFIG_44x iccci0, r0 #endif icbi0,r6 arch/powerpc/kernel/misc32.S: /* * Write any modified data cache blocks out to memory * and invalidate the corresponding instruction cache blocks. * This is a no-op on the 601. * * flush_icache_range(unsigned long start, unsigned long stop) */ _KPROBE(__flush_icache_range) BEGIN_FTR_SECTION blr/* for 601, do nothing */ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) lir5,L1_CACHE_BYTES-1 andcr3,r3,r5 subfr4,r3,r4 addr4,r4,r5 srwi.r4,r4,L1_CACHE_SHIFT beqlr mtctrr4 mrr6,r3 1:dcbst0,r3 addir3,r3,L1_CACHE_BYTES bdnz1b sync/* wait for dcbst's to get to ram */ #ifndef CONFIG_44x mtctrr4 2:icbi0,r6 addir6,r6,L1_CACHE_BYTES bdnz2b #else /* Flash invalidate on 44x because we are passed kmapped addresses and this doesn't work for userspace pages due to the virtually tagged icache. Sigh. */ iccci0, r0 #endif sync/* additional sync needed on g4 */ isync blr Best regards -Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/3] rapidio: changes to enumeration/discovery
Systems that use RapidIO fabric may need to implement their own enumeration and discovery methods which are better suitable for needs of a target application. The following set of patches is intended to simplify process of introduction of new RapidIO fabric enumeration/discovery methods. The first patch offers ability to add new RapidIO enumeration/discovery methods using kernel configuration options. This new configuration option mechanism allows to select statically linked or modular enumeration/discovery method(s) from the list of existing methods or use external module(s). This patch also updates the currently existing enumeration/discovery code to be used as a statically linked or modular method. The corresponding configuration option is named Basic enumeration/discovery method. This is the only one configuration option available today but new methods are expected to be introduced after adoption of provided patches. The second patch address a long time complaint of RapidIO subsystem users regarding fabric enumeration/discovery start sequence. Existing implementation offers only a boot-time enumeration/discovery start which requires synchronized boot of all endpoints in RapidIO network. While it works for small closed configurations with limited number of endpoints, using this approach in systems with large number of endpoints is quite challenging. To eliminate requirement for synchronized start the second patch introduces RapidIO enumeration/discovery start from user space. For compatibility with the existing RapidIO subsystem implementation, automatic boot time enumeration/discovery start can be configured in by specifying rio-scan.scan=1 command line parameter if statically linked basic enumeration method is selected. Changes since v1: (1) Addressed comments made by Andrew Morton for v1: - reworked enumeration/discovery module initialization - added locking for list of mport devices - made mport list static - removed CONFIG_RAPIDIO_ENUM_AUTO option: not needed with new module initialization - added default value for Enumeration method choice in Kconfig Cc: Matt Porter mpor...@kernel.crashing.org Cc: Li Yang le...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org Cc: Andre van Herk andre.van.h...@prodrive.nl Cc: Micha Nelissen micha.nelis...@prodrive.nl Alexandre Bounine (3): rapidio: make enumeration/discovery configurable rapidio: add enumeration/discovery start from user space rapidio: documentation update for enumeration changes Documentation/rapidio/rapidio.txt | 128 ++-- Documentation/rapidio/sysfs.txt | 17 +++ drivers/rapidio/Kconfig | 20 +++ drivers/rapidio/Makefile |3 +- drivers/rapidio/rio-driver.c |8 ++ drivers/rapidio/rio-scan.c| 190 +--- drivers/rapidio/rio-sysfs.c | 45 +++ drivers/rapidio/rio.c | 246 +++- drivers/rapidio/rio.h | 13 ++- include/linux/rio.h | 18 +++- include/linux/rio_drv.h |1 + 11 files changed, 536 insertions(+), 153 deletions(-) -- 1.7.8.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/3] rapidio: documentation update for enumeration changes
Update RapidIO documentation to reflect changes made to enumeration/discovery build configuration and user space triggering mechanism. Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com Cc: Matt Porter mpor...@kernel.crashing.org Cc: Li Yang le...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org Cc: Andre van Herk andre.van.h...@prodrive.nl Cc: Micha Nelissen micha.nelis...@prodrive.nl --- Documentation/rapidio/rapidio.txt | 128 +--- Documentation/rapidio/sysfs.txt | 17 + 2 files changed, 134 insertions(+), 11 deletions(-) diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt index c75694b..a9c16c9 100644 --- a/Documentation/rapidio/rapidio.txt +++ b/Documentation/rapidio/rapidio.txt @@ -79,20 +79,63 @@ master port that is used to communicate with devices within the network. In order to initialize the RapidIO subsystem, a platform must initialize and register at least one master port within the RapidIO network. To register mport within the subsystem controller driver initialization code calls function -rio_register_mport() for each available master port. After all active master -ports are registered with a RapidIO subsystem, the rio_init_mports() routine -is called to perform enumeration and discovery. +rio_register_mport() for each available master port. -In the current PowerPC-based implementation a subsys_initcall() is specified to -perform controller initialization and mport registration. At the end it directly -calls rio_init_mports() to execute RapidIO enumeration and discovery. +RapidIO subsystem uses subsys_initcall() or device_initcall() to perform +controller initialization (depending on controller device type). + +After all active master ports are registered with a RapidIO subsystem, +an enumeration and/or discovery routine may be called automatically or +by user-space command. 4. Enumeration and Discovery -When rio_init_mports() is called it scans a list of registered master ports and -calls an enumeration or discovery routine depending on the configured role of a -master port: host or agent. +4.1 Overview + + +RapidIO subsystem configuration options allow users to specify enumeration and +discovery methods as statically linked components or loadable modules. +An enumeration/discovery method implementation and available input parameters +define how any given method can be attached to available RapidIO mports: +simply to all available mports OR individually to the specified mport device. + +Depending on selected enumeration/discovery build configuration, there are +several methods to initiate an enumeration and/or discovery process: + + (a) Statically linked enumeration and discovery process can be started + automatically during kernel initialization time using corresponding module + parameters. This was the original method used since introduction of RapidIO + subsystem. Now this method relies on enumerator module parameter which is + 'rio-scan.scan' for existing basic enumeration/discovery method. + When automatic start of enumeration/discovery is used a user has to ensure + that all discovering endpoints are started before the enumerating endpoint + and are waiting for enumeration to be completed. + Configuration option CONFIG_RAPIDIO_DISC_TIMEOUT defines time that discovering + endpoint waits for enumeration to be completed. If the specified timeout + expires the discovery process is terminated without obtaining RapidIO network + information. NOTE: a timed out discovery process may be restarted later using + a user-space command as it is described later if the given endpoint was + enumerated successfully. + + (b) Statically linked enumeration and discovery process can be started by + a command from user space. This initiation method provides more flexibility + for a system startup compared to the option (a) above. After all participating + endpoints have been successfully booted, an enumeration process shall be + started first by issuing a user-space command, after an enumeration is + completed a discovery process can be started on all remaining endpoints. + + (c) Modular enumeration and discovery process can be started by a command from + user space. After an enumeration/discovery module is loaded, a network scan + process can be started by issuing a user-space command. + Similar to the option (b) above, an enumerator has to be started first. + + (d) Modular enumeration and discovery process can be started by a module + initialization routine. In this case an enumerating module shall be loaded + first. + +When a network scan process is started it calls an enumeration or discovery +routine depending on the configured role of a master port: host or agent. Enumeration is performed by a master port if it is configured as a host port by assigning a host device ID greater than or equal to zero. A host device ID is @@
[PATCH v2 2/3] rapidio: add enumeration/discovery start from user space
Add RapidIO enumeration/discovery start from user space.
User space start allows to defer RapidIO fabric scan until the moment when all
participating endpoints are initialized avoiding mandatory synchronized start
of all endpoints (which may be challenging in systems with large number of
RapidIO endpoints).
Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com
Cc: Matt Porter mpor...@kernel.crashing.org
Cc: Li Yang le...@freescale.com
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Andre van Herk andre.van.h...@prodrive.nl
Cc: Micha Nelissen micha.nelis...@prodrive.nl
---
drivers/rapidio/rio-driver.c |1 +
drivers/rapidio/rio-scan.c | 24 +++--
drivers/rapidio/rio-sysfs.c | 45 ++
drivers/rapidio/rio.c| 28 -
drivers/rapidio/rio.h|2 +
include/linux/rio.h |9 ++-
6 files changed, 102 insertions(+), 7 deletions(-)
diff --git a/drivers/rapidio/rio-driver.c b/drivers/rapidio/rio-driver.c
index 55850bb..a0c8755 100644
--- a/drivers/rapidio/rio-driver.c
+++ b/drivers/rapidio/rio-driver.c
@@ -207,6 +207,7 @@ struct bus_type rio_bus_type = {
.name = rapidio,
.match = rio_match_bus,
.dev_attrs = rio_dev_attrs,
+ .bus_attrs = rio_bus_attrs,
.probe = rio_device_probe,
.remove = rio_device_remove,
};
diff --git a/drivers/rapidio/rio-scan.c b/drivers/rapidio/rio-scan.c
index 7bdc674..4c15dbf 100644
--- a/drivers/rapidio/rio-scan.c
+++ b/drivers/rapidio/rio-scan.c
@@ -1134,19 +1134,30 @@ static void rio_pw_enable(struct rio_mport *port, int
enable)
/**
* rio_enum_mport- Start enumeration through a master port
* @mport: Master port to send transactions
+ * @flags: Enumeration control flags
*
* Starts the enumeration process. If somebody has enumerated our
* master port device, then give up. If not and we have an active
* link, then start recursive peer enumeration. Returns %0 if
* enumeration succeeds or %-EBUSY if enumeration fails.
*/
-int rio_enum_mport(struct rio_mport *mport)
+int rio_enum_mport(struct rio_mport *mport, u32 flags)
{
struct rio_net *net = NULL;
int rc = 0;
printk(KERN_INFO RIO: enumerate master port %d, %s\n, mport-id,
mport-name);
+
+ /*
+* To avoid multiple start requests (repeat enumeration is not supported
+* by this method) check if enumeration/discovery was performed for this
+* mport: if mport was added into the list of mports for a net exit
+* with error.
+*/
+ if (mport-nnode.next || mport-nnode.prev)
+ return -EBUSY;
+
/* If somebody else enumerated our master port device, bail. */
if (rio_enum_host(mport) 0) {
printk(KERN_INFO
@@ -1236,14 +1247,16 @@ static void rio_build_route_tables(struct rio_net *net)
/**
* rio_disc_mport- Start discovery through a master port
* @mport: Master port to send transactions
+ * @flags: discovery control flags
*
* Starts the discovery process. If we have an active link,
- * then wait for the signal that enumeration is complete.
+ * then wait for the signal that enumeration is complete (if wait
+ * is allowed).
* When enumeration completion is signaled, start recursive
* peer discovery. Returns %0 if discovery succeeds or %-EBUSY
* on failure.
*/
-int rio_disc_mport(struct rio_mport *mport)
+int rio_disc_mport(struct rio_mport *mport, u32 flags)
{
struct rio_net *net = NULL;
unsigned long to_end;
@@ -1253,6 +1266,11 @@ int rio_disc_mport(struct rio_mport *mport)
/* If master port has an active link, allocate net and discover peers */
if (rio_mport_is_active(mport)) {
+ if (rio_enum_complete(mport))
+ goto enum_done;
+ else if (flags RIO_SCAN_ENUM_NO_WAIT)
+ return -EAGAIN;
+
pr_debug(RIO: wait for enumeration to complete...\n);
to_end = jiffies + CONFIG_RAPIDIO_DISC_TIMEOUT * HZ;
diff --git a/drivers/rapidio/rio-sysfs.c b/drivers/rapidio/rio-sysfs.c
index 4dbe360..66d4acd 100644
--- a/drivers/rapidio/rio-sysfs.c
+++ b/drivers/rapidio/rio-sysfs.c
@@ -285,3 +285,48 @@ void rio_remove_sysfs_dev_files(struct rio_dev *rdev)
rdev-rswitch-sw_sysfs(rdev, RIO_SW_SYSFS_REMOVE);
}
}
+
+static ssize_t bus_scan_store(struct bus_type *bus, const char *buf,
+ size_t count)
+{
+ long val;
+ struct rio_mport *port = NULL;
+ int rc;
+
+ if (kstrtol(buf, 0, val) 0)
+ return -EINVAL;
+
+ if (val == RIO_MPORT_ANY) {
+ rc = rio_init_mports();
+ goto exit;
+ }
+
+ if (val 0 || val = RIO_MAX_MPORTS)
+ return -EINVAL;
+
+ port = rio_find_mport((int)val);
+
+ if (!port) {
+ pr_debug(RIO: %s: mport_%d not
[PATCH v2 1/3] rapidio: make enumeration/discovery configurable
Rework to implement RapidIO enumeration/discovery method selection
combined with ability to use enumeration/discovery as a kernel module.
This patch adds ability to introduce new RapidIO enumeration/discovery methods
using kernel configuration options. Configuration option mechanism allows to
select
statically linked or modular enumeration/discovery method from the list of
existing
methods or use external modules.
If a modular enumeration/discovery is selected each RapidIO mport device can
have its own method attached to it.
The existing enumeration/discovery code was updated to be used as statically
linked or modular method. This configuration option is named Basic
enumeration/discovery method.
Several common routines have been moved from rio-scan.c to make them available
to other enumeration methods and reduce number of exported symbols.
Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com
Cc: Matt Porter mpor...@kernel.crashing.org
Cc: Li Yang le...@freescale.com
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Andre van Herk andre.van.h...@prodrive.nl
Cc: Micha Nelissen micha.nelis...@prodrive.nl
---
drivers/rapidio/Kconfig | 20
drivers/rapidio/Makefile |3 +-
drivers/rapidio/rio-driver.c |7 ++
drivers/rapidio/rio-scan.c | 166
drivers/rapidio/rio.c| 222 --
drivers/rapidio/rio.h| 11 ++-
include/linux/rio.h | 13 +++-
include/linux/rio_drv.h |1 +
8 files changed, 304 insertions(+), 139 deletions(-)
diff --git a/drivers/rapidio/Kconfig b/drivers/rapidio/Kconfig
index 6194d35..5ab0564 100644
--- a/drivers/rapidio/Kconfig
+++ b/drivers/rapidio/Kconfig
@@ -47,4 +47,24 @@ config RAPIDIO_DEBUG
If you are unsure about this, say N here.
+choice
+ prompt Enumeration method
+ depends on RAPIDIO
+ default RAPIDIO_ENUM_BASIC
+ help
+ There are different enumeration and discovery mechanisms offered
+ for RapidIO subsystem. You may select single built-in method or
+ or any number of methods to be built as modules.
+ Selecting a built-in method disables use of loadable methods.
+
+ If unsure, select Basic built-in.
+
+config RAPIDIO_ENUM_BASIC
+ tristate Basic
+ help
+ This option includes basic RapidIO fabric enumeration and discovery
+ mechanism similar to one described in RapidIO specification Annex 1.
+
+endchoice
+
source drivers/rapidio/switches/Kconfig
diff --git a/drivers/rapidio/Makefile b/drivers/rapidio/Makefile
index ec3fb81..3036702 100644
--- a/drivers/rapidio/Makefile
+++ b/drivers/rapidio/Makefile
@@ -1,7 +1,8 @@
#
# Makefile for RapidIO interconnect services
#
-obj-y += rio.o rio-access.o rio-driver.o rio-scan.o rio-sysfs.o
+obj-y += rio.o rio-access.o rio-driver.o rio-sysfs.o
+obj-$(CONFIG_RAPIDIO_ENUM_BASIC) += rio-scan.o
obj-$(CONFIG_RAPIDIO) += switches/
obj-$(CONFIG_RAPIDIO) += devices/
diff --git a/drivers/rapidio/rio-driver.c b/drivers/rapidio/rio-driver.c
index 0f4a53b..55850bb 100644
--- a/drivers/rapidio/rio-driver.c
+++ b/drivers/rapidio/rio-driver.c
@@ -164,6 +164,13 @@ void rio_unregister_driver(struct rio_driver *rdrv)
driver_unregister(rdrv-driver);
}
+void rio_attach_device(struct rio_dev *rdev)
+{
+ rdev-dev.bus = rio_bus_type;
+ rdev-dev.parent = rio_bus;
+}
+EXPORT_SYMBOL_GPL(rio_attach_device);
+
/**
* rio_match_bus - Tell if a RIO device structure has a matching RIO driver
device id structure
* @dev: the standard device structure to match against
diff --git a/drivers/rapidio/rio-scan.c b/drivers/rapidio/rio-scan.c
index a965acd..7bdc674 100644
--- a/drivers/rapidio/rio-scan.c
+++ b/drivers/rapidio/rio-scan.c
@@ -37,12 +37,8 @@
#include rio.h
-LIST_HEAD(rio_devices);
-
static void rio_init_em(struct rio_dev *rdev);
-DEFINE_SPINLOCK(rio_global_list_lock);
-
static int next_destid = 0;
static int next_comptag = 1;
@@ -327,127 +323,6 @@ static int rio_is_switch(struct rio_dev *rdev)
}
/**
- * rio_switch_init - Sets switch operations for a particular vendor switch
- * @rdev: RIO device
- * @do_enum: Enumeration/Discovery mode flag
- *
- * Searches the RIO switch ops table for known switch types. If the vid
- * and did match a switch table entry, then call switch initialization
- * routine to setup switch-specific routines.
- */
-static void rio_switch_init(struct rio_dev *rdev, int do_enum)
-{
- struct rio_switch_ops *cur = __start_rio_switch_ops;
- struct rio_switch_ops *end = __end_rio_switch_ops;
-
- while (cur end) {
- if ((cur-vid == rdev-vid) (cur-did == rdev-did)) {
- pr_debug(RIO: calling init routine for %s\n,
-rio_name(rdev));
- cur-init_hook(rdev, do_enum);
- break;
- }
- cur++;
- }
-
Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
On 04/30/2013 02:41 AM, Anthony Foiani wrote: Apologies for resurrecting a very old thread, but... On 05/30/2012 02:14 PM, Anthony Foiani wrote: Maybe someone who knows devtree really well could crank that out in a few minutes... but I'm not that person. :) Well, I wasn't last year, but this year I decided that I didn't care. Took me about an hour, not a minute, but... Having been bitten by this config symbol disappearing one more time, please find attached my attempt at using information out of the device tree to enable this hack. Patch is against 3.4.36 or so; hopefully upstream hasn't diverged very much. Tested by me, so feel free to add that tag if required. Regarding this patch: Search for sata_spd_limit and xxx_spd* functions Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
Scott -- Thanks for the quick reply / review! On 04/30/2013 12:15 PM, Scott Wood wrote: [The devtree approach] might be OK for a new board, but adding it now means that people using existing device trees won't get the workaround. It might be better to just put the knowledge in platform code. That would be fantastic, if I knew what to test. If you look at the thread from last year, it seems that even there in Freescale, nobody knows exactly what triggers this. There was the orphan config value, and I simply turned that into a devtree switch. If you can find an answer inside Freescale, I can try to respin the patch to accommodate that knowledge. But until then, this is the best I can do. (And it's not a new board -- it's based on the 8315ERDB, and the orphaned symbol is apparently related to another 8315 board that never got released?) Please use standard Linux coding style, Huh. I thought I had. I'll double-check. and submit the patch inline rather than as an attachment (e.g. use git send-email). Will see if I can do so. I don't actually have any sort of MTA set up on this machine, hence these Thunderbirded messages. Thanks again, Anthony Foiani ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
On 04/30/2013 07:34:39 PM, Anthony Foiani wrote: Scott -- Thanks for the quick reply / review! On 04/30/2013 12:15 PM, Scott Wood wrote: [The devtree approach] might be OK for a new board, but adding it now means that people using existing device trees won't get the workaround. It might be better to just put the knowledge in platform code. That would be fantastic, if I knew what to test. If you look at the thread from last year, it seems that even there in Freescale, nobody knows exactly what triggers this. There was the orphan config value, and I simply turned that into a devtree switch. If you can find an answer inside Freescale, I can try to respin the patch to accommodate that knowledge. But until then, this is the best I can do. (And it's not a new board -- it's based on the 8315ERDB, and the orphaned symbol is apparently related to another 8315 board that never got released?) I just meant that, for whatever boards you would have put this in the device tree, put it in platform code instead (if the platform file supports more than one board type, then check the compatible at the top of the device tree). Or do you mean that you would not set this on any board's device tree by default, and instead have users set it if they encounter problems? Is this a custom board you're seeing it on? and submit the patch inline rather than as an attachment (e.g. use git send-email). Will see if I can do so. I don't actually have any sort of MTA set up on this machine, hence these Thunderbirded messages. git send-email can connect directly to an SMTP server. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH net-next] af_unix: fix a fatal race with bit fields
From: Eric Dumazet eduma...@google.com
Using bit fields is dangerous on ppc64, as the compiler uses 64bit
instructions to manipulate them. If the 64bit word includes any
atomic_t or spinlock_t, we can lose critical concurrent changes.
This is happening in af_unix, where unix_sk(sk)-gc_candidate/
gc_maybe_cycle/lock share the same 64bit word.
This leads to fatal deadlock, as one/several cpus spin forever
on a spinlock that will never be available again.
Reported-by: Ambrose Feinstein ambr...@google.com
Signed-off-by: Eric Dumazet eduma...@google.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
---
Could ppc64 experts confirm using byte is safe, or should we really add
a 32bit hole after the spinlock ? If so, I wonder how many other places
need a change...
include/net/af_unix.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index a8836e8..4520a23f 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -57,8 +57,8 @@ struct unix_sock {
struct list_headlink;
atomic_long_t inflight;
spinlock_t lock;
- unsigned intgc_candidate : 1;
- unsigned intgc_maybe_cycle : 1;
+ unsigned char gc_candidate;
+ unsigned char gc_maybe_cycle;
unsigned char recursion_level;
struct socket_wqpeer_wq;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] af_unix: fix a fatal race with bit fields
On Tue, 2013-04-30 at 18:12 -0700, Eric Dumazet wrote:
From: Eric Dumazet eduma...@google.com
Using bit fields is dangerous on ppc64, as the compiler uses 64bit
instructions to manipulate them. If the 64bit word includes any
atomic_t or spinlock_t, we can lose critical concurrent changes.
This is happening in af_unix, where unix_sk(sk)-gc_candidate/
gc_maybe_cycle/lock share the same 64bit word.
This leads to fatal deadlock, as one/several cpus spin forever
on a spinlock that will never be available again.
Reported-by: Ambrose Feinstein ambr...@google.com
Signed-off-by: Eric Dumazet eduma...@google.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
---
Could ppc64 experts confirm using byte is safe, or should we really add
a 32bit hole after the spinlock ? If so, I wonder how many other places
need a change...
Wow, nice one !
I'm not even completely certain bytes are safe to be honest, though
probably more than bitfields. I'll poke our compiler people.
The worry is of course how many more of these do we potentially have ?
We might be able to automate finding these issues with sparse, I
suppose.
Also I'd be surprised if ppc64 is the only one with that problem... what
about sparc64 and arm64 ?
Cheers,
Ben.
include/net/af_unix.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index a8836e8..4520a23f 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -57,8 +57,8 @@ struct unix_sock {
struct list_headlink;
atomic_long_t inflight;
spinlock_t lock;
- unsigned intgc_candidate : 1;
- unsigned intgc_maybe_cycle : 1;
+ unsigned char gc_candidate;
+ unsigned char gc_maybe_cycle;
unsigned char recursion_level;
struct socket_wqpeer_wq;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] af_unix: fix a fatal race with bit fields
Hi Eric,
From: Eric Dumazet eduma...@google.com
Using bit fields is dangerous on ppc64, as the compiler uses 64bit
instructions to manipulate them. If the 64bit word includes any
atomic_t or spinlock_t, we can lose critical concurrent changes.
This is happening in af_unix, where unix_sk(sk)-gc_candidate/
gc_maybe_cycle/lock share the same 64bit word.
This leads to fatal deadlock, as one/several cpus spin forever
on a spinlock that will never be available again.
I just spoke to Alan Modra and he suspects this is a compiler
bug. Can you give us your compiler version info?
Anton
Reported-by: Ambrose Feinstein ambr...@google.com
Signed-off-by: Eric Dumazet eduma...@google.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
---
Could ppc64 experts confirm using byte is safe, or should we really
add a 32bit hole after the spinlock ? If so, I wonder how many other
places need a change...
include/net/af_unix.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index a8836e8..4520a23f 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -57,8 +57,8 @@ struct unix_sock {
struct list_headlink;
atomic_long_t inflight;
spinlock_t lock;
- unsigned intgc_candidate : 1;
- unsigned intgc_maybe_cycle : 1;
+ unsigned char gc_candidate;
+ unsigned char gc_maybe_cycle;
unsigned char recursion_level;
struct socket_wqpeer_wq;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the vfs tree with the powerpc tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in
arch/powerpc/kernel/rtas_flash.c between commit fb4696c39573
(powerpc/rtas_flash: Fix bad memory access) from the powerpc tree and
commits ad18a364f186 (powerpc/rtas_flash: Free kmem upon module exit)
and 2352ad01409d (ppc: Clean up rtas_flash driver somewhat) from the
vfs tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/powerpc/kernel/rtas_flash.c
index 243e184,5b77026..000
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@@ -310,9 -316,9 +328,9 @@@ static ssize_t rtas_flash_write(struct
* proc file
*/
if (uf-flist == NULL) {
- uf-flist = kmem_cache_alloc(flash_block_cache, GFP_KERNEL);
+ uf-flist = kmem_cache_zalloc(flash_block_cache, GFP_KERNEL);
if (!uf-flist)
- return -ENOMEM;
+ goto nomem;
}
fl = uf-flist;
@@@ -321,18 -327,18 +339,18 @@@
next_free = fl-num_blocks;
if (next_free == FLASH_BLOCKS_PER_NODE) {
/* Need to allocate another block_list */
- fl-next = kmem_cache_alloc(flash_block_cache, GFP_KERNEL);
+ fl-next = kmem_cache_zalloc(flash_block_cache, GFP_KERNEL);
if (!fl-next)
- return -ENOMEM;
+ goto nomem;
fl = fl-next;
next_free = 0;
}
if (count RTAS_BLK_SIZE)
count = RTAS_BLK_SIZE;
- p = kmem_cache_alloc(flash_block_cache, GFP_KERNEL);
+ p = kmem_cache_zalloc(flash_block_cache, GFP_KERNEL);
if (!p)
- return -ENOMEM;
+ goto nomem;
if(copy_from_user(p, buffer, count)) {
kmem_cache_free(flash_block_cache, p);
@@@ -722,65 -694,13 +706,13 @@@ static int __init rtas_flash_init(void
return 1;
}
- firmware_flash_pde = create_flash_pde(powerpc/rtas/
- FIRMWARE_FLASH_NAME,
- rtas_flash_operations);
- if (firmware_flash_pde == NULL) {
- rc = -ENOMEM;
- goto cleanup;
- }
-
- rc = initialize_flash_pde_data(ibm,update-flash-64-and-reboot,
- sizeof(struct rtas_update_flash_t),
- firmware_flash_pde);
- if (rc != 0)
- goto cleanup;
-
- firmware_update_pde = create_flash_pde(powerpc/rtas/
- FIRMWARE_UPDATE_NAME,
- rtas_flash_operations);
- if (firmware_update_pde == NULL) {
- rc = -ENOMEM;
- goto cleanup;
- }
-
- rc = initialize_flash_pde_data(ibm,update-flash-64-and-reboot,
- sizeof(struct rtas_update_flash_t),
- firmware_update_pde);
- if (rc != 0)
- goto cleanup;
-
- validate_pde = create_flash_pde(powerpc/rtas/ VALIDATE_FLASH_NAME,
- validate_flash_operations);
- if (validate_pde == NULL) {
- rc = -ENOMEM;
- goto cleanup;
- }
-
- rc = initialize_flash_pde_data(ibm,validate-flash-image,
- sizeof(struct rtas_validate_flash_t),
- validate_pde);
- if (rc != 0)
- goto cleanup;
-
- manage_pde = create_flash_pde(powerpc/rtas/ MANAGE_FLASH_NAME,
- manage_flash_operations);
- if (manage_pde == NULL) {
- rc = -ENOMEM;
- goto cleanup;
- }
-
- rc = initialize_flash_pde_data(ibm,manage-flash-image,
- sizeof(struct rtas_manage_flash_t),
- manage_pde);
- if (rc != 0)
- goto cleanup;
-
- rtas_flash_term_hook = rtas_flash_firmware;
+ rtas_validate_flash_data.buf = kzalloc(VALIDATE_BUF_SIZE, GFP_KERNEL);
+ if (!rtas_validate_flash_data.buf)
+ return -ENOMEM;
flash_block_cache = kmem_cache_create(rtas_flash_cache,
-RTAS_BLK_SIZE, RTAS_BLK_SIZE, 0,
-rtas_block_ctor);
+ RTAS_BLK_SIZE, RTAS_BLK_SIZE, 0,
+ NULL);
if (!flash_block_cache) {
printk(KERN_ERR %s: failed to create block cache\n,
__func__);
@@@ -800,20 -742,17 +754,22 @@@ enomem_buf
static void __exit rtas_flash_cleanup(void)
{
+
Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
Scott --
On 04/30/2013 06:42 PM, Scott Wood wrote:
I just meant that, for whatever boards you would have put this in the
device tree, put it in platform code instead (if the platform file
supports more than one board type, then check the compatible at the
top of the device tree).
I think I understand what you're suggesting.
Instead of a new property name, I would instead check for my specific
board type (let's call it a foo-8315) in the top-level compatible list?
So I'd change my devtree to have this top-level compatible:
/ {
compatible = example,foo-8315, fsl,mpc8315erdb;
If I saw that, I would then twiddle the bits as needed?
MIght work, although having it in the sata block of the device tree has
the advantage of providing me exactly the OF node that I need (in
ofdev-dev.of_node). I'd have to figure out how to traverse to the dev
tree root and then back down one to the root compat entry. Probably not
impossible, but I was aiming for a fairly minimal patch.
It would also be nice if we could unravel exactly why that
CONFIG_8315_DS ever showed up in the first place. (The other minimal
aspect of my patch was to try to make changes only around that one area,
so that others could see that it was a simple change.)
Or do you mean that you would not set this on any board's device tree
by default, and instead have users set it if they encounter problems?
No, I would expect to set it on all the boards, so using the
compatibility hack above would work.
Is this a custom board you're seeing it on?
Not ours, but our vendor isn't very active on upstreaming things. (And
yes, had I know that 5 years ago, I could possibly have changed vendors,
or made upstreaming a part of the contract. But at this point, we're
stuck with this vendor, and they're not going to fix it; so I'm trying
to fix it, and I'm trying to do the best job of upstreaming those fixes
that I can.)
git send-email can connect directly to an SMTP server.
Ok, I'll play around with that.
Thanks again,
Anthony
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] af_unix: fix a fatal race with bit fields
On Wed, 2013-05-01 at 11:51 +1000, Anton Blanchard wrote:
Hi Eric,
From: Eric Dumazet eduma...@google.com
Using bit fields is dangerous on ppc64, as the compiler uses 64bit
instructions to manipulate them. If the 64bit word includes any
atomic_t or spinlock_t, we can lose critical concurrent changes.
This is happening in af_unix, where unix_sk(sk)-gc_candidate/
gc_maybe_cycle/lock share the same 64bit word.
This leads to fatal deadlock, as one/several cpus spin forever
on a spinlock that will never be available again.
I just spoke to Alan Modra and he suspects this is a compiler
bug. Can you give us your compiler version info?
$ gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -v
Using built-in specs.
COLLECT_GCC=gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc
COLLECT_LTO_WRAPPER=/usr/local/google/home/edumazet/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/../libexec/gcc/powerpc64-linux/4.6.3/lto-wrapper
Target: powerpc64-linux
Configured with: /home/tony/buildall/src/gcc/configure
--target=powerpc64-linux --host=x86_64-linux-gnu
--build=x86_64-linux-gnu --enable-targets=all
--prefix=/opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/
--enable-languages=c --with-newlib --without-headers
--enable-sjlj-exceptions --with-system-libunwind --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --enable-checking=release
--with-mpfr=/home/tony/buildall/src/sys-x86_64
--with-gmp=/home/tony/buildall/src/sys-x86_64 --disable-bootstrap
--disable-libquadmath
Thread model: single
gcc version 4.6.3 (GCC)
$ cat try.c ; gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc
-O2 -S try.c ; cat try.s
struct s {
unsigned int lock;
unsigned int f1 : 1;
unsigned int f2 : 1;
void *ptr;
} *p ;
showbug()
{
p-lock++;
p-f1 = 1;
}
.file try.c
.section.toc,aw
.section.text
.section.toc,aw
.LC0:
.tc p[TC],p
.section.text
.align 2
.globl showbug
.section.opd,aw
.align 3
showbug:
.quad .L.showbug,.TOC.@tocbase,0
.previous
.type showbug, @function
.L.showbug:
addis 9,2,.LC0@toc@ha
ld 9,.LC0@toc@l(9)
ld 9,0(9)
lwz 11,0(9)
addi 0,11,1
stw 0,0(9)
li 11,1
ld 0,0(9)
rldimi 0,11,31,32
std 0,0(9)
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size showbug,.-.L.showbug
.comm p,8,8
.ident GCC: (GNU) 4.6.3
You can see ld 0,0(9) is used : its a 64 bit load.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] af_unix: fix a fatal race with bit fields
On Tue, Apr 30, 2013 at 07:24:20PM -0700, Eric Dumazet wrote: li 11,1 ld 0,0(9) rldimi 0,11,31,32 std 0,0(9) blr .ident GCC: (GNU) 4.6.3 You can see ld 0,0(9) is used : its a 64 bit load. Yup. This is not a powerpc64 specific problem. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Fixed in 4.8.0 and 4.7.3. -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the vfs tree with the powerpc tree
On 05/01/2013 07:36 AM, Stephen Rothwell wrote: Hi Al, Today's linux-next merge of the vfs tree got a conflict in arch/powerpc/kernel/rtas_flash.c between commit fb4696c39573 (powerpc/rtas_flash: Fix bad memory access) from the powerpc tree and commits ad18a364f186 (powerpc/rtas_flash: Free kmem upon module exit) and 2352ad01409d (ppc: Clean up rtas_flash driver somewhat) from the vfs tree. Stephen, As Ben mentioned earlier, there are outstanding comments from me which needs to be addressed by Dave, before its merged. -Vasant I fixed it up (see below) and can carry the fix as necessary (no action is required). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] af_unix: fix a fatal race with bit fields
On Wed, 2013-05-01 at 13:24 +0930, Alan Modra wrote: On Tue, Apr 30, 2013 at 07:24:20PM -0700, Eric Dumazet wrote: li 11,1 ld 0,0(9) rldimi 0,11,31,32 std 0,0(9) blr .ident GCC: (GNU) 4.6.3 You can see ld 0,0(9) is used : its a 64 bit load. Yup. This is not a powerpc64 specific problem. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Fixed in 4.8.0 and 4.7.3. Ah thanks. This seems a pretty serious issue, is it documented somewhere that ppc64, sparc64 and others need such compiler version ? These kind of errors are pretty hard to find, its a pity to spend time on them. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the vfs tree with the powerpc tree
On Wed, May 01, 2013 at 10:31:33AM +0530, Vasant Hegde wrote: On 05/01/2013 07:36 AM, Stephen Rothwell wrote: Hi Al, Today's linux-next merge of the vfs tree got a conflict in arch/powerpc/kernel/rtas_flash.c between commit fb4696c39573 (powerpc/rtas_flash: Fix bad memory access) from the powerpc tree and commits ad18a364f186 (powerpc/rtas_flash: Free kmem upon module exit) and 2352ad01409d (ppc: Clean up rtas_flash driver somewhat) from the vfs tree. Stephen, As Ben mentioned earlier, there are outstanding comments from me which needs to be addressed by Dave, before its merged. What the hell? Your fixes *are* folded into that commit and according to Ben it passes testing; is there anything still missing? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V7 18/18] powerpc: Update tlbie/tlbiel as per ISA doc
On Tue, Apr 30, 2013 at 10:51:00PM +0530, Aneesh Kumar K.V wrote:
David Gibson d...@au1.ibm.com writes:
On Mon, Apr 29, 2013 at 01:07:39AM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Encode the actual page correctly in tlbie/tlbiel. This make sure we handle
multiple page size segment correctly.
As mentioned in previous comments, this commit message needs to give
much more detail about what precisely the existing implementation is
doing wrong.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/mm/hash_native_64.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hash_native_64.c
b/arch/powerpc/mm/hash_native_64.c
index bb920ee..6a2aead 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -61,7 +61,10 @@ static inline void __tlbie(unsigned long vpn, int
psize, int apsize, int ssize)
switch (psize) {
case MMU_PAGE_4K:
+ /* clear out bits after (52) [052.63] */
+ va = ~((1ul (64 - 52)) - 1);
va |= ssize 8;
+ va |= mmu_psize_defs[apsize].sllp 6;
asm volatile(ASM_FTR_IFCLR(tlbie %0,0, PPC_TLBIE(%1,%0), %2)
: : r (va), r(0), i (CPU_FTR_ARCH_206)
: memory);
@@ -69,9 +72,20 @@ static inline void __tlbie(unsigned long vpn, int
psize, int apsize, int ssize)
default:
/* We need 14 to 14 + i bits of va */
penc = mmu_psize_defs[psize].penc[apsize];
- va = ~((1ul mmu_psize_defs[psize].shift) - 1);
+ va = ~((1ul mmu_psize_defs[apsize].shift) - 1);
va |= penc 12;
va |= ssize 8;
+ /* Add AVAL part */
+ if (psize != apsize) {
+ /*
+ * MPSS, 64K base page size and 16MB parge page size
+ * We don't need all the bits, but rest of the bits
+ * must be ignored by the processor.
+ * vpn cover upto 65 bits of va. (0...65) and we need
+ * 58..64 bits of va.
I can't understand what this comment is saying. Why do we need to do
something different in the psize != apsize case?
+ */
+ va |= (vpn 0xfe);
+ }
That is as per ISA doc. It says if base page size == actual page size,
(RB)56:62 must be zeros, which must be ignored by the processor.
Otherwise it should be filled with the selected bits of VA as explained above.
What you've just said here makes much more sense than what's written
in the comment in the code.
We only support MPSS with base page size = 64K and actual page size = 16MB.
Is that actually relevant to this code though?
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
