11.13Sriastrad/*	$NetBSD: membar_ops.S,v 1.13 2022/04/21 12:06:31 riastradh Exp $	*/
21.1Sad
31.1Sad/*-
41.1Sad * Copyright (c) 2006, 2007 The NetBSD Foundation, Inc.
51.1Sad * All rights reserved.
61.1Sad *
71.1Sad * This code is derived from software contributed to The NetBSD Foundation
81.1Sad * by Jason R. Thorpe, and by Andrew Doran.
91.1Sad *
101.1Sad * Redistribution and use in source and binary forms, with or without
111.1Sad * modification, are permitted provided that the following conditions
121.1Sad * are met:
131.1Sad * 1. Redistributions of source code must retain the above copyright
141.1Sad *    notice, this list of conditions and the following disclaimer.
151.1Sad * 2. Redistributions in binary form must reproduce the above copyright
161.1Sad *    notice, this list of conditions and the following disclaimer in the
171.1Sad *    documentation and/or other materials provided with the distribution.
181.9Sskrll *
191.1Sad * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
201.1Sad * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
211.1Sad * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
221.1Sad * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
231.1Sad * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
241.1Sad * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
251.1Sad * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
261.1Sad * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
271.1Sad * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
281.1Sad * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
291.1Sad * POSSIBILITY OF SUCH DAMAGE.
301.1Sad */
311.1Sad
321.1Sad#include "atomic_op_asm.h"
331.1Sad
341.1Sad	.text
351.5Smatt	.set noreorder
361.1Sad
371.3SchsLEAF(_membar_sync)
381.4Smatt	j	ra
391.10Sskrll	 BDSYNC
401.1SadEND(_membar_sync)
411.13SriastradATOMIC_OP_ALIAS(membar_sync,_membar_sync)
421.13Sriastrad
431.13SriastradSTRONG_ALIAS(_membar_enter,_membar_sync)
441.13SriastradATOMIC_OP_ALIAS(membar_enter,_membar_sync)
451.1Sad
461.6Smatt#ifdef __OCTEON__
471.13Sriastrad
481.13Sriastrad/*
491.13Sriastrad * cnMIPS guarantees load-before-load/store ordering without any
501.13Sriastrad * barriers.  So the only barriers we need are store-before-load (sync)
511.13Sriastrad * and store-before-store (syncw, i.e., sync 4).  See Table 2-32
521.13Sriastrad * `Execution Ordering Rules' on p. 104 of Cavium OCTEON III CN78XX
531.13Sriastrad * Hardware Reference Manual, CN78XX-HM-0.99E, September 2014:
541.13Sriastrad *
551.13Sriastrad *	First Operation		DLD [load instruction to a physical
561.13Sriastrad *				address that is L2/DRAM]
571.13Sriastrad *	Second Operation	Any
581.13Sriastrad *	Execution Ordering Comments
591.13Sriastrad *
601.13Sriastrad *		The second operation cannot appear to execute before
611.13Sriastrad *		the first (DLD) operation, regardless of the presence
621.13Sriastrad *		or absence of SYNC* instructions.
631.13Sriastrad *
641.13Sriastrad * Note: I'm not sure if this applies to earlier cnMIPS -- can't find
651.13Sriastrad * it in the Cavium Networks OCTEON Plus CN50XX Hardware Reference
661.13Sriastrad * Manual CN50XX-HM-0.99E, July 2008.  Experimentally, on an erlite3
671.13Sriastrad * (Cavium Octeon CN5020-500), I can easily detect reordering of
681.13Sriastrad * store-before-store and store-before-load, but I haven't been able to
691.13Sriastrad * detect any reordering of load-before-load or load-before-store.
701.13Sriastrad *
711.13Sriastrad * Note: On early cnMIPS (CN3xxx), there is an erratum which sometimes
721.13Sriastrad * requires issuing two syncw's in a row.  I don't know the details --
731.13Sriastrad * don't have documentation -- and in Linux it is only used for I/O
741.13Sriastrad * purposes.
751.13Sriastrad *
761.13Sriastrad * Currently we don't build kernels that work on both Octeon and
771.13Sriastrad * non-Octeon MIPS CPUs, so none of this is done with binary patching.
781.13Sriastrad * For userlands we could use a separate shared library on Octeon with
791.13Sriastrad * ld.so.conf to override the symbols with cheaper definitions, but we
801.13Sriastrad * don't do that now.
811.13Sriastrad */
821.13Sriastrad
831.13SriastradLEAF(_membar_acquire)
841.13Sriastrad	j	ra
851.13Sriastrad	 nop
861.13SriastradEND(_membar_acquire)
871.13SriastradATOMIC_OP_ALIAS(membar_acquire,_membar_acquire)
881.13Sriastrad
891.13SriastradSTRONG_ALIAS(_membar_consumer,_membar_acquire)
901.13SriastradATOMIC_OP_ALIAS(membar_consumer,_membar_acquire)
911.13Sriastrad
921.12SriastradLEAF(_membar_release)
931.6Smatt	j	ra
941.6Smatt	 syncw
951.12SriastradEND(_membar_release)
961.13SriastradATOMIC_OP_ALIAS(membar_release,_membar_release)
971.6Smatt
981.13SriastradSTRONG_ALIAS(_membar_exit,_membar_release)
991.12SriastradATOMIC_OP_ALIAS(membar_exit,_membar_release)
1001.13Sriastrad
1011.13SriastradSTRONG_ALIAS(_membar_producer,_membar_release)
1021.12SriastradATOMIC_OP_ALIAS(membar_producer,_membar_release)
1031.13Sriastrad
1041.13Sriastrad#else  /* !__OCTEON__ */
1051.13Sriastrad
1061.13SriastradSTRONG_ALIAS(_membar_acquire,_membar_sync)
1071.13SriastradATOMIC_OP_ALIAS(membar_acquire,_membar_sync)
1081.13SriastradSTRONG_ALIAS(_membar_release,_membar_sync)
1091.13SriastradATOMIC_OP_ALIAS(membar_release,_membar_sync)
1101.13SriastradSTRONG_ALIAS(_membar_exit,_membar_sync)
1111.1SadATOMIC_OP_ALIAS(membar_exit,_membar_sync)
1121.13SriastradSTRONG_ALIAS(_membar_consumer,_membar_sync)
1131.13SriastradATOMIC_OP_ALIAS(membar_consumer,_membar_sync)
1141.13SriastradSTRONG_ALIAS(_membar_producer,_membar_sync)
1151.1SadATOMIC_OP_ALIAS(membar_producer,_membar_sync)
1161.13Sriastrad
1171.6Smatt#endif
118