RE: [V2,1/2] powerpc/fsl: Add PCI node in device tree of bsc9132qds

2015-10-18 Thread Hou Zhiqiang 


> -Original Message-
> From: Wood Scott-B07421
> Sent: 2015年10月17日 9:34
> To: Hou Zhiqiang-B48286
> Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org;
> b...@kernel.crashing.org; pau...@samba.org; m...@ellerman.id.au;
> devicet...@vger.kernel.org; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; Rai Harninder-B01044;
> Lian Minghuan-B31939; Hu Mingkai-B21284
> Subject: Re: [V2,1/2] powerpc/fsl: Add PCI node in device tree of
> bsc9132qds
> 
> On Fri, Oct 16, 2015 at 05:01:10PM +0800, Zhiqiang Hou wrote:
> > From: Harninder Rai 
> >
> > Signed-off-by: Harninder Rai 
> > Signed-off-by: Minghuan Lian 
> > Change-Id: I4355add4a92d1fcf514843aea5ecadd2e2517969
> > Reviewed-on: http://git.am.freescale.net:8181/2454
> > Reviewed-by: Zang Tiefei-R61911 
> > Reviewed-by: Kushwaha Prabhakar-B32579 
> > Reviewed-by: Fleming Andrew-AFLEMING 
> > Tested-by: Fleming Andrew-AFLEMING 
> 
> Again:
> 
> Get rid of the gerrit stuff.  And where is your signoff?

Ok.

Thanks,
Zhiqiang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V4 00/31] powerpc/mm: Update page table format for book3s 64

2015-10-18 Thread Aneesh Kumar K.V 
Benjamin Herrenschmidt  writes:

> On Sat, 2015-10-17 at 15:38 +0530, Aneesh Kumar K.V wrote:
>> Hi All,
>> 
>> This patch series attempt to update book3s 64 linux page table format to
>> make it more flexible. Our current pte format is very restrictive and we
>> overload multiple pte bits. This is due to the non-availability of free bits
>> in pte_t. We use pte_t to track the validity of 4K subpages. This patch
>> series free up pte_t of 11 bits by moving 4K subpage tracking to the
>> lower half of PTE page. The pte format is updated such that we have a
>> better method for identifying a pte entry at pmd level. This will also enable
>> us to implement hugetlb migration(not yet done in this series). 
>
> I still have serious concerns about the fact that we now use 4 times
> more memory for page tables than strictly necessary. We were using
> twice as much before.
>
> We need to find a way to not allocate all those "other halves" when not
> needed.
>
> I understand it's tricky, we tend to notice we need the second half too
> late...
>
> Maybe if we could escalate the hash miss into a minor fault when the
> second half is needed and not present, we can then allocate it from the
>
> For demotion of the vmap space, we might have to be a bit smarter,
> maybe detect at ioremap/vmap time and flag the mm as needed second
> halves for everything (and allocate them).
>
> Of course if the machine doesn't do hw 64k, we would always allocate
> the second half.
>
> The question then becomes how to reference it from the first half.
>
> A completely parallel tree means a lot more walks for each PTE, is
> there something in the PTE page's struct page we can use maybe ?
>

We could use page->index. I have an early patch (it still find wrong
ptes ) which increase fragment count to 32. IMHO, we should
get this series merged and not depend on increasing fragment
count to 32 now. I was planning to get that merged in the next
merge window. We get sufficient time to test and also won't push
all the changes in one merge window. This will allow us to easily
isolate issues if they arise. 

powerpc/mm: Move subpage tracking allocation out of pgtable

This is the first part of the attempt to reduce pagetable usage for 64k.
The goal is to allocate 4k subpage tracking memory only if we need to

Not-Signed-off-by: Aneesh Kumar K.V 

diff --git a/arch/powerpc/include/asm/pgalloc-64.h 
b/arch/powerpc/include/asm/pgalloc-64.h
index 4f1cc6c46728..f4243d9264c4 100644
--- a/arch/powerpc/include/asm/pgalloc-64.h
+++ b/arch/powerpc/include/asm/pgalloc-64.h
@@ -166,13 +166,24 @@ static inline void __pte_free_tlb(struct mmu_gather *tlb, 
pgtable_t table,
 /*
  * we support 8 fragments per PTE page.
  */
-#define PTE_FRAG_NR8
+#define PTE_FRAG_NR32
 /*
  * We use a 2K PTE page fragment and another 4K for storing
  * real_pte_t hash index. Rounding the entire thing to 8K
  */
-#define PTE_FRAG_SIZE_SHIFT  13
+#define PTE_FRAG_SIZE_SHIFT  11
 #define PTE_FRAG_SIZE (1UL << PTE_FRAG_SIZE_SHIFT)
+/*
+ * Size of array used to track the respective 4K subpage details
+ * Total entries in a pte page:
+ * (PTE_FRAG_NR * PTE_FRAG_SIZE) / 8
+ * Space needed per 64K pte:
+ * 16 bytes (One byte per 4K hpte)
+ * Total space for 4K PTE frag size
+ * (PTE_FRAG_NR * PTE_FRAG_SIZE) * 2
+ * ie, order 1 pages.
+ */
+#define PTE_4K_FRAG_SIZE (PTE_FRAG_SIZE << 1)
 
 extern pte_t *page_table_alloc(struct mm_struct *, unsigned long, int);
 extern void page_table_free(struct mm_struct *, unsigned long *, int);
diff --git a/arch/powerpc/mm/hash64_64k.c b/arch/powerpc/mm/hash64_64k.c
index 84867a1491a2..08c141a844ca 100644
--- a/arch/powerpc/mm/hash64_64k.c
+++ b/arch/powerpc/mm/hash64_64k.c
@@ -15,24 +15,40 @@
 #include 
 #include 
 #include 
+#include 
+
+static inline int pte_frag_index(unsigned long ptep, unsigned long pte_page)
+{
+   return  (ptep - pte_page)/ PTE_FRAG_SIZE;
+
+}
+
+static inline int pte_4k_track_index(int frag_index, int pte_index)
+{
+   return (PTE_4K_FRAG_SIZE * frag_index) + (pte_index * 16);
+
+}
 
 real_pte_t __real_pte(unsigned long addr, pte_t pte, pte_t *ptep)
 {
int indx;
real_pte_t rpte;
-   pte_t *pte_headp;
+   struct page *pte_page = virt_to_page(ptep);
 
rpte.pte = pte;
rpte.hidx = NULL;
if (pte_val(pte) & _PAGE_COMBO) {
+   int frag_index = pte_frag_index((unsigned long) ptep,
+   (unsigned long)page_address(pte_page));
+
indx = pte_index(addr);
-   pte_headp = ptep - indx;
/*
 * Make sure we order the hidx load against the _PAGE_COMBO
 * check. The store side ordering is done in __hash_page_4K
 */
smp_rmb();
-   rpte.hidx = (unsigned char *)(pte_headp + PTRS_PER_PTE) + (16 * 
indx);
+   rpte.hidx = ((unsigned char

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

2015-10-18 Thread Boqun Feng 
On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> On Fri, Oct 09, 2015 at 10:31:38AM +0200, Peter Zijlstra wrote:
[snip]
> > 
> > So lots of little confusions added up to complete fail :-{
> > 
> > Mostly I think it was the UNLOCK x + LOCK x are fully ordered (where I
> > forgot: but not against uninvolved CPUs) and RELEASE/ACQUIRE are
> > transitive (where I forgot: RELEASE/ACQUIRE _chains_ are transitive, but
> > again not against uninvolved CPUs).
> > 
> > Which leads me to think I would like to suggest alternative rules for
> > RELEASE/ACQUIRE (to replace those Will suggested; as I think those are
> > partly responsible for my confusion).
> 
> Yeah, sorry. I originally used the phrase "fully ordered" but changed it
> to "full barrier", which has stronger transitivity (newly understood
> definition) requirements that I didn't intend.
> 
> RELEASE -> ACQUIRE should be used for message passing between two CPUs
> and not have ordering effects on other observers unless they're part of
> the RELEASE -> ACQUIRE chain.
> 
> >  - RELEASE -> ACQUIRE is fully ordered (but not a full barrier) when
> >they operate on the same variable and the ACQUIRE reads from the
> >RELEASE. Notable, RELEASE/ACQUIRE are RCpc and lack transitivity.
> 
> Are we explicit about the difference between "fully ordered" and "full
> barrier" somewhere else, because this looks like it will confuse people.
> 

This is confusing me right now. ;-)

Let's use a simple example for only one primitive, as I understand it,
if we say a primitive A is "fully ordered", we actually mean:

1.  The memory operations preceding(in program order) A can't be
reordered after the memory operations following(in PO) A.

and

2.  The memory operation(s) in A can't be reordered before the
memory operations preceding(in PO) A and after the memory
operations following(in PO) A.

If we say A is a "full barrier", we actually means:

1.  The memory operations preceding(in program order) A can't be
reordered after the memory operations following(in PO) A.

and

2.  The memory ordering guarantee in #1 is visible globally.

Is that correct? Or "full barrier" is more strong than I understand,
i.e. there is a third property of "full barrier":

3.  The memory operation(s) in A can't be reordered before the
memory operations preceding(in PO) A and after the memory
operations following(in PO) A.

IOW, is "full barrier" a more strong version of "fully ordered" or not?

Regards,
Boqun

> >  - RELEASE -> ACQUIRE can be upgraded to a full barrier (including
> >transitivity) using smp_mb__release_acquire(), either before RELEASE
> >or after ACQUIRE (but consistently [*]).
> 
> Hmm, but we don't actually need this for RELEASE -> ACQUIRE, afaict. This
> is just needed for UNLOCK -> LOCK, and is exactly what RCU is currently
> using (for PPC only).
> 
> Stepping back a second, I believe that there are three cases:
> 
> 
>  RELEASE X -> ACQUIRE Y (same CPU)
>* Needs a barrier on TSO architectures for full ordering
> 
>  UNLOCK X -> LOCK Y (same CPU)
>* Needs a barrier on PPC for full ordering
> 
>  RELEASE X -> ACQUIRE X (different CPUs)
>  UNLOCK X -> ACQUIRE X (different CPUs)
>* Fully ordered everywhere...
>* ... but needs a barrier on PPC to become a full barrier
> 
> 


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 0/5] drivers/tty: make more bool drivers explicitly non-modular

2015-10-18 Thread Paul Gortmaker 
This next set of patches to drivers/tty fixes up more drivers that would
perhaps appear modular when looking at the code, but are controlled by
a bool Kconfig.  We make sure they don't look modular and get rid
of module related code in the drivers that would never be used.

The one common thread here for all the patches is that we also
scrap the .remove functions which would only be used for module
unload (impossible) and driver unbind.  For the drivers here, there
doesn't seem to be a sensible unbind use case (vs. e.g. a multiport
PCI ethernet driver where one port is unbound and passed through to
a kvm guest or similar).  Hence we just explicitly disallow any
driver unbind operations to help prevent root from doing something
illogical to the machine that they could have done previously.

We've already done this for drivers/tty/serial/mpsc.c previously.

Build tested for allmodconfig on ARM64 and powerpc for tty/tty-testing.

Paul.

---

Cc: Andy Gross 
Cc: Anton Blanchard 
Cc: David Brown 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Kumar Gala 
Cc: Matthias Brugger 
Cc: Michael Ellerman 
Cc: Nicolas Ferre 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ser...@vger.kernel.org
Cc: linux-...@vger.kernel.org

Paul Gortmaker (5):
  drivers/tty: make hvc/hvc_vio.c explicitly non-modular
  drivers/tty: make ehv_bytechan.c explicitly non-modular
  drivers/tty/serial: make serial/atmel_serial.c explicitly non-modular
  drivers/tty/serial: make msm_serial.c explicitly non-modular
  drivers/tty/serial: make 8250/8250_mtk.c explicitly non-modular

 drivers/tty/ehv_bytechan.c | 40 +++--
 drivers/tty/hvc/hvc_vio.c  | 29 
 drivers/tty/serial/8250/8250_mtk.c | 35 ++---
 drivers/tty/serial/atmel_serial.c  | 45 --
 drivers/tty/serial/msm_serial.c| 30 -
 5 files changed, 22 insertions(+), 157 deletions(-)

-- 
2.6.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/5] drivers/tty: make ehv_bytechan.c explicitly non-modular

2015-10-18 Thread Paul Gortmaker 
The Kconfig currently controlling compilation of this code is:

drivers/tty/Kconfig:config PPC_EPAPR_HV_BYTECHAN
drivers/tty/Kconfig:bool "ePAPR hypervisor byte channel driver"

...meaning that it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker 
---
 drivers/tty/ehv_bytechan.c | 40 +++-
 1 file changed, 3 insertions(+), 37 deletions(-)

diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index 342b36b9ad35..7ac9bcdf1e61 100644
--- a/drivers/tty/ehv_bytechan.c
+++ b/drivers/tty/ehv_bytechan.c
@@ -23,7 +23,6 @@
  * byte channel used for the console is designated as the default tty.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -719,19 +718,6 @@ error:
return ret;
 }
 
-static int ehv_bc_tty_remove(struct platform_device *pdev)
-{
-   struct ehv_bc_data *bc = dev_get_drvdata(>dev);
-
-   tty_unregister_device(ehv_bc_driver, bc - bcs);
-
-   tty_port_destroy(>port);
-   irq_dispose_mapping(bc->tx_irq);
-   irq_dispose_mapping(bc->rx_irq);
-
-   return 0;
-}
-
 static const struct of_device_id ehv_bc_tty_of_ids[] = {
{ .compatible = "epapr,hv-byte-channel" },
{}
@@ -741,15 +727,15 @@ static struct platform_driver ehv_bc_tty_driver = {
.driver = {
.name = "ehv-bc",
.of_match_table = ehv_bc_tty_of_ids,
+   .suppress_bind_attrs = true,
},
.probe  = ehv_bc_tty_probe,
-   .remove = ehv_bc_tty_remove,
 };
 
 /**
  * ehv_bc_init - ePAPR hypervisor byte channel driver initialization
  *
- * This function is called when this module is loaded.
+ * This function is called when this driver is loaded.
  */
 static int __init ehv_bc_init(void)
 {
@@ -814,24 +800,4 @@ error:
 
return ret;
 }
-
-
-/**
- * ehv_bc_exit - ePAPR hypervisor byte channel driver termination
- *
- * This function is called when this driver is unloaded.
- */
-static void __exit ehv_bc_exit(void)
-{
-   platform_driver_unregister(_bc_tty_driver);
-   tty_unregister_driver(ehv_bc_driver);
-   put_tty_driver(ehv_bc_driver);
-   kfree(bcs);
-}
-
-module_init(ehv_bc_init);
-module_exit(ehv_bc_exit);
-
-MODULE_AUTHOR("Timur Tabi ");
-MODULE_DESCRIPTION("ePAPR hypervisor byte channel driver");
-MODULE_LICENSE("GPL v2");
+device_initcall(ehv_bc_init);
-- 
2.6.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] powerpc/mpc5xxx: Avoid dereferencing potentially freed memory

2015-10-18 Thread Michael Ellerman 
On Fri, 2015-10-16 at 22:05 +0200, Christophe JAILLET wrote:
> Hi,
> sorry if un-clear.
> 
> What I mean is that in the patch related 
> 'powerpc/sysdev/mpc5xxx_clocks.c', there was no call to 'be32_to_cpup'.
> So in the proposed patch, 'of_property_read_u32' adds it.
> 
> While in the patch against 'powerpc/kernel/prom.c', 'be32_to_cpup' was 
> called explicitly.
> So using 'of_property_read_u32' keep the same logic.

Ah right, I understand now.

> Basically the code from 'mpc5xxx_clocks.c' and from 'prom.c' were 
> written the same way. I found spurious that a call to 'be32_to_cpup' was 
> done in only one case.
> Maybe, it was a missing in 'mpc5xxx_clocks.c'.

Yes it was missing in that code.

But that's not a real bug because that code only ever runs on BE systems.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/ps3: Quieten the build when building ps3

2015-10-18 Thread Michael Ellerman 
The boot wrapper uses dd when building for ps3, which annoyingly tells
us in great detail what it's doing, eg:

  512+0 records in
  512+0 records out
  512 bytes (512 B) copied, 0.000802129 s, 638 kB/s
  512+0 records in
  512+0 records out
  512 bytes (512 B) copied, 0.000745101 s, 687 kB/s

Also annoyingly, there is no "quiet" flag to dd, so our only option is
to grab all the output from dd, and iff there is an error print it out.

As it turns out we used to do this, so this is actually a partial revert
of commit d47403733403 ("[POWERPC] bootwrapper: Bail from script if any
command fails").

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/boot/wrapper | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 3f50c27ed8f8..b7d353b88029 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -456,13 +456,27 @@ ps3)
 
 ${CROSS}objcopy -O binary "$ofile" "$ofile.bin"
 
-dd if="$ofile.bin" of="$ofile.bin" conv=notrunc   \
-skip=$overlay_dest seek=$system_reset_kernel  \
-count=$overlay_size bs=1
+set +e
 
-dd if="$ofile.bin" of="$ofile.bin" conv=notrunc   \
-skip=$system_reset_overlay seek=$overlay_dest \
-count=$overlay_size bs=1
+msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc   \
+  skip=$overlay_dest seek=$system_reset_kernel  \
+  count=$overlay_size bs=1 2>&1)
+
+if [ $? -ne "0" ]; then
+echo $msg
+exit 1
+fi
+
+msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc   \
+  skip=$system_reset_overlay seek=$overlay_dest \
+  count=$overlay_size bs=1 2>&1)
+
+if [ $? -ne "0" ]; then
+echo $msg
+exit 2
+fi
+
+set -e
 
 odir="$(dirname "$ofile.bin")"
 rm -f "$odir/otheros.bld"
-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/5] drivers/tty: make hvc/hvc_vio.c explicitly non-modular

2015-10-18 Thread Paul Gortmaker 
The Kconfig currently controlling compilation of this code is:

drivers/tty/hvc/Kconfig:config HVC_CONSOLE
drivers/tty/hvc/Kconfig:bool "pSeries Hypervisor Virtual Console 
support"

...meaning that it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.

We don't replace module.h with init.h since the file already has that.

Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Michael Ellerman 
Cc: Anton Blanchard 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker 
---
 drivers/tty/hvc/hvc_vio.c | 29 -
 1 file changed, 4 insertions(+), 25 deletions(-)

diff --git a/drivers/tty/hvc/hvc_vio.c b/drivers/tty/hvc/hvc_vio.c
index f575a9b5ede7..b05dc5086627 100644
--- a/drivers/tty/hvc/hvc_vio.c
+++ b/drivers/tty/hvc/hvc_vio.c
@@ -41,7 +41,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -61,7 +60,6 @@ static struct vio_device_id hvc_driver_table[] = {
 #endif
{ "", "" }
 };
-MODULE_DEVICE_TABLE(vio, hvc_driver_table);
 
 typedef enum hv_protocol {
HV_PROTOCOL_RAW,
@@ -363,26 +361,13 @@ static int hvc_vio_probe(struct vio_dev *vdev,
return 0;
 }
 
-static int hvc_vio_remove(struct vio_dev *vdev)
-{
-   struct hvc_struct *hp = dev_get_drvdata(>dev);
-   int rc, termno;
-
-   termno = hp->vtermno;
-   rc = hvc_remove(hp);
-   if (rc == 0) {
-   if (hvterm_privs[termno] != _priv0)
-   kfree(hvterm_privs[termno]);
-   hvterm_privs[termno] = NULL;
-   }
-   return rc;
-}
-
 static struct vio_driver hvc_vio_driver = {
.id_table   = hvc_driver_table,
.probe  = hvc_vio_probe,
-   .remove = hvc_vio_remove,
.name   = hvc_driver_name,
+   .driver = {
+   .suppress_bind_attrs= true,
+   },
 };
 
 static int __init hvc_vio_init(void)
@@ -394,13 +379,7 @@ static int __init hvc_vio_init(void)
 
return rc;
 }
-module_init(hvc_vio_init); /* after drivers/char/hvc_console.c */
-
-static void __exit hvc_vio_exit(void)
-{
-   vio_unregister_driver(_vio_driver);
-}
-module_exit(hvc_vio_exit);
+device_initcall(hvc_vio_init); /* after drivers/tty/hvc/hvc_console.c */
 
 void __init hvc_vio_init_early(void)
 {
-- 
2.6.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

2015-10-18 Thread Boqun Feng 
On Thu, Oct 15, 2015 at 09:30:40AM -0700, Paul E. McKenney wrote:
> On Thu, Oct 15, 2015 at 12:48:03PM +0800, Boqun Feng wrote:
> > On Wed, Oct 14, 2015 at 08:07:05PM -0700, Paul E. McKenney wrote:
[snip]
> > 
> > > Why not try creating a longer litmus test that requires P0's write to
> > > "a" to propagate to P1 before both processes complete?
> > > 
> > 
> > I will try to write one, but to be clear, you mean we still observe 
> > 
> > 0:r3 == 0 && a == 2 && 1:r3 == 0 
> > 
> > at the end, right? Because I understand that if P1's write to 'a'
> > doesn't override P0's, P0's write to 'a' will propagate.
> 
> Your choice.  My question is whether you can come up with a similar
> litmus test where lwsync is allowing the behavior here, but clearly
> is affecting some other aspect of ordering.
> 

Got it, though my question about the propagation of P0's write to 'a'
was originally aimed at understanding the hardware behavior(or model) in
your sequence of events ;-)

To be clear, by "some other aspect of ordering", you mean something like
a paired RELEASE+ACQUIRE senario(i.e. P1 observes P0's write to 'a' via
a load, which means P0's write to 'a' propagates at some point), right?

If so I haven't yet came up with one, and I think there's probably none,
so my worry about "lwsync" in other places is likely unnecessary.

Regards,
Boqun


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] selftests/powerpc: run eeb tests only on POWER8

2015-10-18 Thread Denis Kirjanov 
On 10/18/15, Michael Ellerman  wrote:
> On Sat, 2015-10-17 at 21:31 +0300, Denis Kirjanov wrote:
>
>> Event Based Branches currenly available on POWER8.
>> so we can skip them on other CPUs.
>
> Thanks for the patch, but ..
>
>> I've found that at least one test loops forever
>> on 970MP (cycles_with_freeze_test).
>
> Ooo interesting. The harness should kill it after a timeout.
>
>> diff --git a/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
>> b/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
>> index d7a72ce..a252637 100644
>> --- a/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
>> +++ b/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
>> @@ -319,6 +319,19 @@ void ebb_global_disable(void)
>>  mb();
>>  }
>>
>> +#define PVR_VER(pvr)(((pvr) >>  16) & 0x)
>> +bool ebb_is_supported(void)
>> +{
>> +unsigned long pvr;
>> +
>> +__asm__ __volatile__("mfpvr %0" : "=b"(pvr));
>> +/* EBB requires at least POWER8 */
>> +if (PVR_VER(pvr) >= 0x004D)
>> +return true;
>> +
>> +return false;
>> +}
>
> The right way to do this is not to look at the PVR but instead look at
> AT_HWCAP2, and see if it contains PPC_FEATURE2_EBB.
>
> You can see an example in tm-syscall.c
>
> Can you please respin with that change?

Sure, no problem!

Thanks!

>
> cheers
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] selftests/powerpc: run eeb tests only on POWER8

2015-10-18 Thread Michael Ellerman 
On Sat, 2015-10-17 at 21:31 +0300, Denis Kirjanov wrote:

> Event Based Branches currenly available on POWER8.
> so we can skip them on other CPUs.

Thanks for the patch, but ..

> I've found that at least one test loops forever
> on 970MP (cycles_with_freeze_test).

Ooo interesting. The harness should kill it after a timeout.

> diff --git a/tools/testing/selftests/powerpc/pmu/ebb/ebb.c 
> b/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> index d7a72ce..a252637 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/ebb.c
> @@ -319,6 +319,19 @@ void ebb_global_disable(void)
>   mb();
>  }
>  
> +#define PVR_VER(pvr)(((pvr) >>  16) & 0x)
> +bool ebb_is_supported(void)
> +{
> + unsigned long pvr;
> +
> + __asm__ __volatile__("mfpvr %0" : "=b"(pvr));
> + /* EBB requires at least POWER8 */
> + if (PVR_VER(pvr) >= 0x004D)
> + return true;
> +
> + return false;
> +}

The right way to do this is not to look at the PVR but instead look at
AT_HWCAP2, and see if it contains PPC_FEATURE2_EBB.

You can see an example in tm-syscall.c

Can you please respin with that change?

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2] selftests/powerpc: run eeb tests only on POWER8

2015-10-18 Thread Denis Kirjanov 
Event Based Branches currenly available on POWER8.
so we can skip them on other CPUs.

I've found that at least one test loops forever
on 970MP (cycles_with_freeze_test).

Signed-off-by: Denis Kirjanov 

v2 changes:
 - use get_auxv_entry() helper to get supported features
---
 .../selftests/powerpc/pmu/ebb/back_to_back_ebbs_test.c|  2 ++
 .../selftests/powerpc/pmu/ebb/close_clears_pmcc_test.c|  2 ++
 .../selftests/powerpc/pmu/ebb/cpu_event_pinned_vs_ebb_test.c  |  2 ++
 tools/testing/selftests/powerpc/pmu/ebb/cycles_test.c |  2 ++
 .../selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c   |  2 ++
 .../selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c|  2 ++
 tools/testing/selftests/powerpc/pmu/ebb/ebb.c | 11 +++
 tools/testing/selftests/powerpc/pmu/ebb/ebb.h |  1 +
 tools/testing/selftests/powerpc/pmu/ebb/ebb_on_child_test.c   |  2 ++
 .../selftests/powerpc/pmu/ebb/ebb_on_willing_child_test.c |  2 ++
 .../testing/selftests/powerpc/pmu/ebb/ebb_vs_cpu_event_test.c |  2 ++
 .../testing/selftests/powerpc/pmu/ebb/event_attributes_test.c |  2 ++
 tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c   |  2 ++
 .../selftests/powerpc/pmu/ebb/instruction_count_test.c|  2 ++
 tools/testing/selftests/powerpc/pmu/ebb/lost_exception_test.c |  2 ++
 tools/testing/selftests/powerpc/pmu/ebb/multi_counter_test.c  |  2 ++
 .../testing/selftests/powerpc/pmu/ebb/multi_ebb_procs_test.c  |  2 ++
 tools/testing/selftests/powerpc/pmu/ebb/no_handler_test.c |  2 ++
 tools/testing/selftests/powerpc/pmu/ebb/pmae_handling_test.c  |  2 ++
 tools/testing/selftests/powerpc/pmu/ebb/pmc56_overflow_test.c |  2 ++
 tools/testing/selftests/powerpc/pmu/ebb/reg_access_test.c |  2 ++
 .../selftests/powerpc/pmu/ebb/task_event_pinned_vs_ebb_test.c |  2 ++
 .../selftests/powerpc/pmu/ebb/task_event_vs_ebb_test.c|  2 ++
 23 files changed, 54 insertions(+)

diff --git a/tools/testing/selftests/powerpc/pmu/ebb/back_to_back_ebbs_test.c 
b/tools/testing/selftests/powerpc/pmu/ebb/back_to_back_ebbs_test.c
index 66ea765..94110b1 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/back_to_back_ebbs_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/back_to_back_ebbs_test.c
@@ -63,6 +63,8 @@ int back_to_back_ebbs(void)
 {
struct event event;
 
+   SKIP_IF(!ebb_is_supported());
+
event_init_named(, 0x1001e, "cycles");
event_leader_ebb_init();
 
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/close_clears_pmcc_test.c 
b/tools/testing/selftests/powerpc/pmu/ebb/close_clears_pmcc_test.c
index 0f0423d..ac18cf6 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/close_clears_pmcc_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/close_clears_pmcc_test.c
@@ -20,6 +20,8 @@ int close_clears_pmcc(void)
 {
struct event event;
 
+   SKIP_IF(!ebb_is_supported());
+
event_init_named(, 0x1001e, "cycles");
event_leader_ebb_init();
 
diff --git 
a/tools/testing/selftests/powerpc/pmu/ebb/cpu_event_pinned_vs_ebb_test.c 
b/tools/testing/selftests/powerpc/pmu/ebb/cpu_event_pinned_vs_ebb_test.c
index d3ed64d..f0632e7 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/cpu_event_pinned_vs_ebb_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/cpu_event_pinned_vs_ebb_test.c
@@ -43,6 +43,8 @@ int cpu_event_pinned_vs_ebb(void)
int cpu, rc;
pid_t pid;
 
+   SKIP_IF(!ebb_is_supported());
+
cpu = pick_online_cpu();
FAIL_IF(cpu < 0);
FAIL_IF(bind_to_cpu(cpu));
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/cycles_test.c 
b/tools/testing/selftests/powerpc/pmu/ebb/cycles_test.c
index 8590fc1..7c57a8d 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/cycles_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/cycles_test.c
@@ -16,6 +16,8 @@ int cycles(void)
 {
struct event event;
 
+   SKIP_IF(!ebb_is_supported());
+
event_init_named(, 0x1001e, "cycles");
event_leader_ebb_init();
 
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c 
b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
index 754b3f2..ecf5ee3 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_freeze_test.c
@@ -56,6 +56,8 @@ int cycles_with_freeze(void)
uint64_t val;
bool fc_cleared;
 
+   SKIP_IF(!ebb_is_supported());
+
event_init_named(, 0x1001e, "cycles");
event_leader_ebb_init();
 
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c 
b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c
index d43029b..c0faba5 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c
@@ -26,6 +26,8 @@ int cycles_with_mmcr2(void)
int i;
bool bad_mmcr2;
 
+