* [PATCH 09/20] ASoC: imx-spdif: Switch to SPDX identifier
From: Andra Danciu @ 2019-04-05 11:49 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Andra Danciu, daniel.baluta
In-Reply-To: <20190405115010.28838-1-andradanciu1997@gmail.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu <andradanciu1997@gmail.com>
---
sound/soc/fsl/imx-spdif.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/sound/soc/fsl/imx-spdif.c b/sound/soc/fsl/imx-spdif.c
index 797d66e43d49..4f7f210beb18 100644
--- a/sound/soc/fsl/imx-spdif.c
+++ b/sound/soc/fsl/imx-spdif.c
@@ -1,13 +1,6 @@
-/*
- * Copyright (C) 2013 Freescale Semiconductor, Inc.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright (C) 2013 Freescale Semiconductor, Inc.
#include <linux/module.h>
#include <linux/of_platform.h>
--
2.11.0
^ permalink raw reply related
* [PATCH 08/20] ASoC: imx-pcm-fiq: Switch to SPDX identifier
From: Andra Danciu @ 2019-04-05 11:49 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Andra Danciu, daniel.baluta
In-Reply-To: <20190405115010.28838-1-andradanciu1997@gmail.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu <andradanciu1997@gmail.com>
---
sound/soc/fsl/imx-pcm-fiq.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/imx-pcm-fiq.c b/sound/soc/fsl/imx-pcm-fiq.c
index 0578f3486847..c49aea4fba56 100644
--- a/sound/soc/fsl/imx-pcm-fiq.c
+++ b/sound/soc/fsl/imx-pcm-fiq.c
@@ -1,16 +1,11 @@
-/*
- * imx-pcm-fiq.c -- ALSA Soc Audio Layer
- *
- * Copyright 2009 Sascha Hauer <s.hauer@pengutronix.de>
- *
- * This code is based on code copyrighted by Freescale,
- * Liam Girdwood, Javier Martin and probably others.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
+// SPDX-License-Identifier: GPL-2.0+
+// imx-pcm-fiq.c -- ALSA Soc Audio Layer
+//
+// Copyright 2009 Sascha Hauer <s.hauer@pengutronix.de>
+//
+// This code is based on code copyrighted by Freescale,
+// Liam Girdwood, Javier Martin and probably others.
+
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/device.h>
--
2.11.0
^ permalink raw reply related
* [PATCH 07/20] ASoC: imx-mc13783: Switch to SPDX identifier
From: Andra Danciu @ 2019-04-05 11:49 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Andra Danciu, daniel.baluta
In-Reply-To: <20190405115010.28838-1-andradanciu1997@gmail.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu <andradanciu1997@gmail.com>
---
sound/soc/fsl/imx-mc13783.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/sound/soc/fsl/imx-mc13783.c b/sound/soc/fsl/imx-mc13783.c
index 9d19b808f634..545815a27074 100644
--- a/sound/soc/fsl/imx-mc13783.c
+++ b/sound/soc/fsl/imx-mc13783.c
@@ -1,17 +1,11 @@
-/*
- * imx-mc13783.c -- SoC audio for imx based boards with mc13783 codec
- *
- * Copyright 2012 Philippe Retornaz, <philippe.retornaz@epfl.ch>
- *
- * Heavly based on phycore-mc13783:
- * Copyright 2009 Sascha Hauer, Pengutronix <s.hauer@pengutronix.de>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// imx-mc13783.c -- SoC audio for imx based boards with mc13783 codec
+//
+// Copyright 2012 Philippe Retornaz, <philippe.retornaz@epfl.ch>
+//
+// Heavly based on phycore-mc13783:
+// Copyright 2009 Sascha Hauer, Pengutronix <s.hauer@pengutronix.de>
#include <linux/module.h>
#include <linux/moduleparam.h>
--
2.11.0
^ permalink raw reply related
* [PATCH 06/20] ASoC: imx-es8328: Switch to SPDX identifier
From: Andra Danciu @ 2019-04-05 11:49 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Andra Danciu, daniel.baluta
In-Reply-To: <20190405115010.28838-1-andradanciu1997@gmail.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu <andradanciu1997@gmail.com>
---
sound/soc/fsl/imx-es8328.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/sound/soc/fsl/imx-es8328.c b/sound/soc/fsl/imx-es8328.c
index 9953438086e4..c9d8739b04a9 100644
--- a/sound/soc/fsl/imx-es8328.c
+++ b/sound/soc/fsl/imx-es8328.c
@@ -1,14 +1,7 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- * Copyright 2012 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2012 Linaro Ltd.
#include <linux/gpio.h>
#include <linux/module.h>
--
2.11.0
^ permalink raw reply related
* [PATCH 05/20] ASoC: imx-audmux: Switch to SPDX identifier
From: Andra Danciu @ 2019-04-05 11:49 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Andra Danciu, daniel.baluta
In-Reply-To: <20190405115010.28838-1-andradanciu1997@gmail.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu <andradanciu1997@gmail.com>
---
sound/soc/fsl/imx-audmux.c | 26 ++++++++------------------
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/sound/soc/fsl/imx-audmux.c b/sound/soc/fsl/imx-audmux.c
index 99e07b01a2ce..04e59e66711d 100644
--- a/sound/soc/fsl/imx-audmux.c
+++ b/sound/soc/fsl/imx-audmux.c
@@ -1,21 +1,11 @@
-/*
- * Copyright 2012 Freescale Semiconductor, Inc.
- * Copyright 2012 Linaro Ltd.
- * Copyright 2009 Pengutronix, Sascha Hauer <s.hauer@pengutronix.de>
- *
- * Initial development of this code was funded by
- * Phytec Messtechnik GmbH, http://www.phytec.de
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * 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.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2012 Linaro Ltd.
+// Copyright 2009 Pengutronix, Sascha Hauer <s.hauer@pengutronix.de>
+//
+// Initial development of this code was funded by
+// Phytec Messtechnik GmbH, http://www.phytec.de
#include <linux/clk.h>
#include <linux/debugfs.h>
--
2.11.0
^ permalink raw reply related
* [PATCH 04/20] ASoC: fsl-dma: Switch to SPDX identifier
From: Andra Danciu @ 2019-04-05 11:49 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Andra Danciu, daniel.baluta
In-Reply-To: <20190405115010.28838-1-andradanciu1997@gmail.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu <andradanciu1997@gmail.com>
---
sound/soc/fsl/fsl_dma.c | 26 +++++++++++---------------
sound/soc/fsl/fsl_dma.h | 5 +----
2 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
index 78871de35086..e22508301412 100644
--- a/sound/soc/fsl/fsl_dma.c
+++ b/sound/soc/fsl/fsl_dma.c
@@ -1,18 +1,14 @@
-/*
- * Freescale DMA ALSA SoC PCM driver
- *
- * Author: Timur Tabi <timur@freescale.com>
- *
- * Copyright 2007-2010 Freescale Semiconductor, Inc.
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- *
- * This driver implements ASoC support for the Elo DMA controller, which is
- * the DMA controller on Freescale 83xx, 85xx, and 86xx SOCs. In ALSA terms,
- * the PCM driver is what handles the DMA buffer.
- */
+// SPDX-License-Identifier: GPL-2.0
+//
+// Freescale DMA ALSA SoC PCM driver
+//
+// Author: Timur Tabi <timur@freescale.com>
+//
+// Copyright 2007-2010 Freescale Semiconductor, Inc.
+//
+// This driver implements ASoC support for the Elo DMA controller, which is
+// the DMA controller on Freescale 83xx, 85xx, and 86xx SOCs. In ALSA terms,
+// the PCM driver is what handles the DMA buffer.
#include <linux/module.h>
#include <linux/init.h>
diff --git a/sound/soc/fsl/fsl_dma.h b/sound/soc/fsl/fsl_dma.h
index 78fee97e8036..f19ae765b656 100644
--- a/sound/soc/fsl/fsl_dma.h
+++ b/sound/soc/fsl/fsl_dma.h
@@ -1,9 +1,6 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* mpc8610-pcm.h - ALSA PCM interface for the Freescale MPC8610 SoC
- *
- * 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.
*/
#ifndef _MPC8610_PCM_H
--
2.11.0
^ permalink raw reply related
* [PATCH 03/20] ASoC: eukrea-tlv320: Switch to SPDX identifier
From: Andra Danciu @ 2019-04-05 11:49 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Andra Danciu, daniel.baluta
In-Reply-To: <20190405115010.28838-1-andradanciu1997@gmail.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu <andradanciu1997@gmail.com>
---
sound/soc/fsl/eukrea-tlv320.c | 26 ++++++++++----------------
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/sound/soc/fsl/eukrea-tlv320.c b/sound/soc/fsl/eukrea-tlv320.c
index 30a3d68b5c03..d648268cb454 100644
--- a/sound/soc/fsl/eukrea-tlv320.c
+++ b/sound/soc/fsl/eukrea-tlv320.c
@@ -1,19 +1,13 @@
-/*
- * eukrea-tlv320.c -- SoC audio for eukrea_cpuimxXX in I2S mode
- *
- * Copyright 2010 Eric Bénard, Eukréa Electromatique <eric@eukrea.com>
- *
- * based on sound/soc/s3c24xx/s3c24xx_simtec_tlv320aic23.c
- * which is Copyright 2009 Simtec Electronics
- * and on sound/soc/imx/phycore-ac97.c which is
- * Copyright 2009 Sascha Hauer, Pengutronix <s.hauer@pengutronix.de>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// eukrea-tlv320.c -- SoC audio for eukrea_cpuimxXX in I2S mode
+//
+// Copyright 2010 Eric Bénard, Eukréa Electromatique <eric@eukrea.com>
+//
+// based on sound/soc/s3c24xx/s3c24xx_simtec_tlv320aic23.c
+// which is Copyright 2009 Simtec Electronics
+// and on sound/soc/imx/phycore-ac97.c which is
+// Copyright 2009 Sascha Hauer, Pengutronix <s.hauer@pengutronix.de>
#include <linux/errno.h>
#include <linux/module.h>
--
2.11.0
^ permalink raw reply related
* [PATCH 02/20] ASoC: efika-audio-fabric.c: Switch to SPDX identifier
From: Andra Danciu @ 2019-04-05 11:49 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Andra Danciu, daniel.baluta
In-Reply-To: <20190405115010.28838-1-andradanciu1997@gmail.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu <andradanciu1997@gmail.com>
---
sound/soc/fsl/efika-audio-fabric.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/sound/soc/fsl/efika-audio-fabric.c b/sound/soc/fsl/efika-audio-fabric.c
index 667f4215dfc0..3e832902fc99 100644
--- a/sound/soc/fsl/efika-audio-fabric.c
+++ b/sound/soc/fsl/efika-audio-fabric.c
@@ -1,14 +1,9 @@
-/*
- * Efika driver for the PSC of the Freescale MPC52xx
- * configured as AC97 interface
- *
- * Copyright 2008 Jon Smirl, Digispeaker
- * Author: Jon Smirl <jonsmirl@gmail.com>
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- */
+// SPDX-License-Identifier: GPL-2.0
+// Efika driver for the PSC of the Freescale MPC52xx
+// configured as AC97 interface
+//
+// Copyright 2008 Jon Smirl, Digispeaker
+// Author: Jon Smirl <jonsmirl@gmail.com>
#include <linux/init.h>
#include <linux/module.h>
--
2.11.0
^ permalink raw reply related
* [PATCH 00/20] Switch to SPDX identifier
From: Andra Danciu @ 2019-04-05 11:49 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Andra Danciu, daniel.baluta
This patch set switches to SPDX identifier inside the fsl directory.
Andra Danciu (20):
ASoC: imx-pcm: Switch to SPDX identifier
ASoC: efika-audio-fabric.c: Switch to SPDX identifier
ASoC: eukrea-tlv320: Switch to SPDX identifier
ASoC: fsl-dma: Switch to SPDX identifier
ASoC: imx-audmux: Switch to SPDX identifier
ASoC: imx-es8328: Switch to SPDX identifier
ASoC: imx-mc13783: Switch to SPDX identifier
ASoC: imx-pcm-fiq: Switch to SPDX identifier
ASoC: imx-spdif: Switch to SPDX identifier
ASoC: imx-ssi: Switch to SPDX identifier
ASoC: mpc5200_dma: Switch to SPDX identifier
ASoC: mpc5200_psc_ac97: Switch to SPDX identifier
ASoC: mpc5200_psc_i2s: Switch to SPDX identifier
ASoC: mpc8610_hpcd: Switch to SPDX identifier
ASoC: mx27vis-aic32x4: Switch to SPDX identifier
ASoC: p1022_ds: Switch to SPDX identifier
ASoC: p1022_rdk: Switch to SPDX identifier
ASoC: pcm030-audio-fabric: Switch to SPDX identifier
ASoC: phycore-ac97: Switch to SPDX identifier
ASoC: wm1133-ev1: Switch to SPDX identifier
sound/soc/fsl/efika-audio-fabric.c | 17 ++++-------
sound/soc/fsl/eukrea-tlv320.c | 26 +++++++----------
sound/soc/fsl/fsl_dma.c | 26 +++++++----------
sound/soc/fsl/fsl_dma.h | 5 +---
sound/soc/fsl/imx-audmux.c | 26 ++++++-----------
sound/soc/fsl/imx-es8328.c | 15 +++-------
sound/soc/fsl/imx-mc13783.c | 22 ++++++--------
sound/soc/fsl/imx-pcm-fiq.c | 21 ++++++--------
sound/soc/fsl/imx-pcm.h | 6 +---
sound/soc/fsl/imx-spdif.c | 13 ++-------
sound/soc/fsl/imx-ssi.c | 57 ++++++++++++++++---------------------
sound/soc/fsl/imx-ssi.h | 6 +---
sound/soc/fsl/mpc5200_dma.c | 14 ++++-----
sound/soc/fsl/mpc5200_psc_ac97.c | 16 ++++-------
sound/soc/fsl/mpc5200_psc_i2s.c | 14 ++++-----
sound/soc/fsl/mpc8610_hpcd.c | 18 +++++-------
sound/soc/fsl/mx27vis-aic32x4.c | 29 +++++--------------
sound/soc/fsl/p1022_ds.c | 18 +++++-------
sound/soc/fsl/p1022_rdk.c | 32 +++++++++------------
sound/soc/fsl/pcm030-audio-fabric.c | 18 +++++-------
sound/soc/fsl/phycore-ac97.c | 16 ++++-------
sound/soc/fsl/wm1133-ev1.c | 21 ++++++--------
22 files changed, 161 insertions(+), 275 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 01/20] ASoC: imx-pcm: Switch to SPDX identifier
From: Andra Danciu @ 2019-04-05 11:49 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Andra Danciu, daniel.baluta
In-Reply-To: <20190405115010.28838-1-andradanciu1997@gmail.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Andra Danciu <andradanciu1997@gmail.com>
---
sound/soc/fsl/imx-pcm.h | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index 133c4470acad..5dd406774d3e 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -1,13 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
/*
* Copyright 2009 Sascha Hauer <s.hauer@pengutronix.de>
*
* This code is based on code copyrighted by Freescale,
* Liam Girdwood, Javier Martin and probably others.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
#ifndef _IMX_PCM_H
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/2] cpuidle : Add auto-promotion flag to cpuidle flags
From: Abhishek Goel @ 2019-04-05 9:16 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-pm
Cc: Abhishek Goel, daniel.lezcano, rjw, ego
In-Reply-To: <20190405091647.4169-1-huntbag@linux.vnet.ibm.com>
This patch sets up flags for the state which needs to be auto-promoted. On
POWERNV system, only lite states need to be autopromoted. We identify lite
states by those which do not lose user context. That information has been
used to set the flag for lite states.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal-api.h | 1 +
drivers/cpuidle/Kconfig | 4 ++++
drivers/cpuidle/cpuidle-powernv.c | 13 +++++++++++--
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
index 870fb7b23..735dec731 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -226,6 +226,7 @@
*/
#define OPAL_PM_TIMEBASE_STOP 0x00000002
+#define OPAL_PM_LOSE_USER_CONTEXT 0x00001000
#define OPAL_PM_LOSE_HYP_CONTEXT 0x00002000
#define OPAL_PM_LOSE_FULL_CONTEXT 0x00004000
#define OPAL_PM_NAP_ENABLED 0x00010000
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index 8caccbbd7..9b8e9b96a 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -35,6 +35,10 @@ config CPU_IDLE_GOV_TEO
config DT_IDLE_STATES
bool
+config CPU_IDLE_AUTO_PROMOTION
+ bool
+ default y if PPC_POWERNV
+
menu "ARM CPU Idle Drivers"
depends on ARM || ARM64
source "drivers/cpuidle/Kconfig.arm"
diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
index 84b1ebe21..0dd767270 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -299,6 +299,7 @@ static int powernv_add_idle_states(void)
for (i = 0; i < dt_idle_states; i++) {
unsigned int exit_latency, target_residency;
bool stops_timebase = false;
+ bool lose_user_context = false;
struct pnv_idle_states_t *state = &pnv_idle_states[i];
/*
@@ -324,6 +325,9 @@ static int powernv_add_idle_states(void)
if (has_stop_states && !(state->valid))
continue;
+ if (state->flags & OPAL_PM_LOSE_USER_CONTEXT)
+ lose_user_context = true;
+
if (state->flags & OPAL_PM_TIMEBASE_STOP)
stops_timebase = true;
@@ -332,12 +336,17 @@ static int powernv_add_idle_states(void)
add_powernv_state(nr_idle_states, "Nap",
CPUIDLE_FLAG_NONE, nap_loop,
target_residency, exit_latency, 0, 0);
+ } else if (has_stop_states && !lose_user_context) {
+ add_powernv_state(nr_idle_states, state->name,
+ CPUIDLE_FLAG_AUTO_PROMOTION,
+ stop_loop, target_residency,
+ exit_latency, state->psscr_val,
+ state->psscr_mask);
} else if (has_stop_states && !stops_timebase) {
add_powernv_state(nr_idle_states, state->name,
CPUIDLE_FLAG_NONE, stop_loop,
target_residency, exit_latency,
- state->psscr_val,
- state->psscr_mask);
+ state->psscr_val, state->psscr_mask);
}
/*
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/2] cpuidle : auto-promotion for cpuidle states
From: Abhishek Goel @ 2019-04-05 9:16 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-pm
Cc: Abhishek Goel, daniel.lezcano, rjw, ego
In-Reply-To: <20190405091647.4169-1-huntbag@linux.vnet.ibm.com>
Currently, the cpuidle governors (menu /ladder) determine what idle state
an idling CPU should enter into based on heuristics that depend on the
idle history on that CPU. Given that no predictive heuristic is perfect,
there are cases where the governor predicts a shallow idle state, hoping
that the CPU will be busy soon. However, if no new workload is scheduled
on that CPU in the near future, the CPU will end up in the shallow state.
In case of POWER, this is problematic, when the predicted state in the
aforementioned scenario is a lite stop state, as such lite states will
inhibit SMT folding, thereby depriving the other threads in the core from
using the core resources.
To address this, such lite states need to be autopromoted. The cpuidle-
core can queue timer to correspond with the residency value of the next
available state. Thus leading to auto-promotion to a deeper idle state as
soon as possible.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
---
v1->v2 : Removed timeout_needed and rebased to current upstream kernel
drivers/cpuidle/cpuidle.c | 68 +++++++++++++++++++++++++++++-
drivers/cpuidle/governors/ladder.c | 3 +-
| 22 +++++++++-
include/linux/cpuidle.h | 10 ++++-
4 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 7f108309e..11ce43f19 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -36,6 +36,11 @@ static int enabled_devices;
static int off __read_mostly;
static int initialized __read_mostly;
+struct auto_promotion {
+ struct hrtimer hrtimer;
+ unsigned long timeout_us;
+};
+
int cpuidle_disabled(void)
{
return off;
@@ -188,6 +193,54 @@ int cpuidle_enter_s2idle(struct cpuidle_driver *drv, struct cpuidle_device *dev)
}
#endif /* CONFIG_SUSPEND */
+enum hrtimer_restart auto_promotion_hrtimer_callback(struct hrtimer *hrtimer)
+{
+ return HRTIMER_NORESTART;
+}
+
+#ifdef CONFIG_CPU_IDLE_AUTO_PROMOTION
+DEFINE_PER_CPU(struct auto_promotion, ap);
+
+static void cpuidle_auto_promotion_start(int cpu, struct cpuidle_state *state)
+{
+ struct auto_promotion *this_ap = &per_cpu(ap, cpu);
+
+ if (state->flags & CPUIDLE_FLAG_AUTO_PROMOTION)
+ hrtimer_start(&this_ap->hrtimer, ns_to_ktime(this_ap->timeout_us
+ * 1000), HRTIMER_MODE_REL_PINNED);
+}
+
+static void cpuidle_auto_promotion_cancel(int cpu)
+{
+ struct hrtimer *hrtimer;
+
+ hrtimer = &per_cpu(ap, cpu).hrtimer;
+ if (hrtimer_is_queued(hrtimer))
+ hrtimer_cancel(hrtimer);
+}
+
+static void cpuidle_auto_promotion_update(int cpu, unsigned long timeout)
+{
+ per_cpu(ap, cpu).timeout_us = timeout;
+}
+
+static void cpuidle_auto_promotion_init(int cpu, struct cpuidle_driver *drv)
+{
+ struct auto_promotion *this_ap = &per_cpu(ap, cpu);
+
+ hrtimer_init(&this_ap->hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ this_ap->hrtimer.function = auto_promotion_hrtimer_callback;
+}
+#else
+static inline void cpuidle_auto_promotion_start(int cpu, struct cpuidle_state
+ *state) { }
+static inline void cpuidle_auto_promotion_cancel(int cpu) { }
+static inline void cpuidle_auto_promotion_update(int cpu, unsigned long
+ timeout) { }
+static inline void cpuidle_auto_promotion_init(int cpu, struct cpuidle_driver
+ *drv) { }
+#endif
+
/**
* cpuidle_enter_state - enter the state and update stats
* @dev: cpuidle device for this cpu
@@ -225,12 +278,17 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
trace_cpu_idle_rcuidle(index, dev->cpu);
time_start = ns_to_ktime(local_clock());
+ cpuidle_auto_promotion_start(dev->cpu, target_state);
+
stop_critical_timings();
entered_state = target_state->enter(dev, drv, index);
start_critical_timings();
sched_clock_idle_wakeup_event();
time_end = ns_to_ktime(local_clock());
+
+ cpuidle_auto_promotion_cancel(dev->cpu);
+
trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
/* The cpu is no longer idle or about to enter idle. */
@@ -312,7 +370,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
bool *stop_tick)
{
- return cpuidle_curr_governor->select(drv, dev, stop_tick);
+ unsigned long timeout_us, ret;
+
+ timeout_us = UINT_MAX;
+ ret = cpuidle_curr_governor->select(drv, dev, stop_tick, &timeout_us);
+ cpuidle_auto_promotion_update(dev->cpu, timeout_us);
+
+ return ret;
}
/**
@@ -658,6 +722,8 @@ int cpuidle_register(struct cpuidle_driver *drv,
device = &per_cpu(cpuidle_dev, cpu);
device->cpu = cpu;
+ cpuidle_auto_promotion_init(cpu, drv);
+
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
/*
* On multiplatform for ARM, the coupled idle states could be
diff --git a/drivers/cpuidle/governors/ladder.c b/drivers/cpuidle/governors/ladder.c
index f0dddc66a..65b518dd7 100644
--- a/drivers/cpuidle/governors/ladder.c
+++ b/drivers/cpuidle/governors/ladder.c
@@ -64,7 +64,8 @@ static inline void ladder_do_selection(struct ladder_device *ldev,
* @dummy: not used
*/
static int ladder_select_state(struct cpuidle_driver *drv,
- struct cpuidle_device *dev, bool *dummy)
+ struct cpuidle_device *dev, bool *dummy,
+ unsigned long *unused)
{
struct ladder_device *ldev = this_cpu_ptr(&ladder_devices);
struct ladder_device_state *last_state;
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 5951604e7..835e337de 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -276,7 +276,7 @@ static unsigned int get_typical_interval(struct menu_device *data,
* @stop_tick: indication on whether or not to stop the tick
*/
static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
- bool *stop_tick)
+ bool *stop_tick, unsigned long *timeout)
{
struct menu_device *data = this_cpu_ptr(&menu_devices);
int latency_req = cpuidle_governor_latency_req(dev->cpu);
@@ -442,6 +442,26 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
}
}
+#ifdef CPUIDLE_FLAG_AUTO_PROMOTION
+ if (drv->states[idx].flags & CPUIDLE_FLAG_AUTO_PROMOTION) {
+ /*
+ * Timeout is intended to be defined as sum of target residency
+ * of next available state, entry latency and exit latency. If
+ * time interval equal to timeout is spent in current state,
+ * and if it is a shallow lite state, we may want to auto-
+ * promote from such state.
+ */
+ for (i = idx + 1; i < drv->state_count; i++) {
+ if (drv->states[i].disabled ||
+ dev->states_usage[i].disable)
+ continue;
+ *timeout = drv->states[i].target_residency +
+ 2 * drv->states[i].exit_latency;
+ break;
+ }
+ }
+#endif
+
return idx;
}
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 3b3947232..84d76d1ec 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -72,6 +72,13 @@ struct cpuidle_state {
#define CPUIDLE_FLAG_POLLING BIT(0) /* polling state */
#define CPUIDLE_FLAG_COUPLED BIT(1) /* state applies to multiple cpus */
#define CPUIDLE_FLAG_TIMER_STOP BIT(2) /* timer is stopped on this state */
+/*
+ * State with only and only fast state bit set don't even lose user context.
+ * But such states prevent other sibling threads from thread folding benefits.
+ * And hence we don't want to stay for too long in such states and want to
+ * auto-promote from it.
+ */
+#define CPUIDLE_FLAG_AUTO_PROMOTION BIT(3)
struct cpuidle_device_kobj;
struct cpuidle_state_kobj;
@@ -243,7 +250,8 @@ struct cpuidle_governor {
int (*select) (struct cpuidle_driver *drv,
struct cpuidle_device *dev,
- bool *stop_tick);
+ bool *stop_tick, unsigned long
+ *timeout);
void (*reflect) (struct cpuidle_device *dev, int index);
};
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/2] Auto-promotion logic for cpuidle states
From: Abhishek Goel @ 2019-04-05 9:16 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-pm
Cc: Abhishek Goel, daniel.lezcano, rjw, ego
Currently, the cpuidle governors (menu/ladder) determine what idle state a
idling CPU should enter into based on heuristics that depend on the idle
history on that CPU. Given that no predictive heuristic is perfect, there
are cases where the governor predicts a shallow idle state, hoping that
the CPU will be busy soon. However, if no new workload is scheduled on
that CPU in the near future, the CPU will end up in the shallow state.
Motivation
----------
In case of POWER, this is problematic, when the predicted state in the
aforementioned scenario is a lite stop state, as such lite states will
inhibit SMT folding, thereby depriving the other threads in the core from
using the core resources.
To address this, such lite states need to be autopromoted. The cpuidle-core
can queue timer to correspond with the residency value of the next
available state. Thus leading to auto-promotion to a deeper idle state as
soon as possible.
Experiment
----------
I performed experiments for three scenarios to collect some data.
case 1 :
Without this patch and without tick retained, i.e. in a upstream kernel,
It would spend more than even a second to get out of stop0_lite.
case 2 : With tick retained(as suggested) -
Generally, we have a sched tick at 4ms(CONF_HZ = 250). Ideally I expected
it to take 8 sched tick to get out of stop0_lite. Experimentally,
observation was
=========================================================
sample min max 99percentile
20 4ms 12ms 4ms
=========================================================
*ms = milliseconds
It would take atleast one sched tick to get out of stop0_lite.
case 2 : With this patch (not stopping tick, but explicitly queuing a
timer)
============================================================
sample min max 99percentile
============================================================
20 144us 192us 144us
============================================================
*us = microseconds
In this patch, we queue a timer just before entering into a stop0_lite
state. The timer fires at (residency of next available state + exit latency
of next available state * 2). Let's say if next state(stop0) is available
which has residency of 20us, it should get out in as low as (20+2*2)*8
[Based on the forumla (residency + 2xlatency)*history length] microseconds
= 192us. Ideally we would expect 8 iterations, it was observed to get out
in 6-7 iterations. Even if let's say stop2 is next available state(stop0
and stop1 both are unavailable), it would take (100+2*10)*8 = 960us to get
into stop2.
So, We are able to get out of stop0_lite generally in 150us(with this
patch) as compared to 4ms(with tick retained). As stated earlier, we do not
want to get stuck into stop0_lite as it inhibits SMT folding for other
sibling threads, depriving them of core resources. Current patch is using
auto-promotion only for stop0_lite, as it gives performance benefit(primary
reason) along with lowering down power consumption. We may extend this
model for other states in future.
Abhishek Goel (2):
cpuidle : auto-promotion for cpuidle states
cpuidle : Add auto-promotion flag to cpuidle flags
arch/powerpc/include/asm/opal-api.h | 1 +
drivers/cpuidle/Kconfig | 4 ++
drivers/cpuidle/cpuidle-powernv.c | 13 +++++-
drivers/cpuidle/cpuidle.c | 68 ++++++++++++++++++++++++++++-
drivers/cpuidle/governors/ladder.c | 3 +-
drivers/cpuidle/governors/menu.c | 22 +++++++++-
include/linux/cpuidle.h | 10 ++++-
7 files changed, 115 insertions(+), 6 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [1/5] powerpc/sparse: fix possible object reference leak
From: Markus Elfring @ 2019-04-05 8:50 UTC (permalink / raw)
To: Wen Yang, linuxppc-dev, kernel-janitors
Cc: Yi Wang, Paul Mackerras, linux-kernel
In-Reply-To: <1553223955-7350-1-git-send-email-wen.yang99@zte.com.cn>
> @@ -131,7 +131,7 @@ static int drc_index_to_cpu(u32 drc_index)
>
> of_read_drc_info_cell(&info, &value, &drc);
> if (strncmp(drc.drc_type, "CPU", 3))
> - goto err;
> + goto err_of_node_put;
>
> if (drc_index > drc.last_drc_index) {
Can the jump label “put_node” be nicer here?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v4 4/4] ocxl: Remove some unused exported symbols
From: Andrew Donnellan @ 2019-04-05 7:28 UTC (permalink / raw)
To: Alastair D'Silva, alastair
Cc: Frederic Barrat, Greg Kroah-Hartman, linuxppc-dev, linux-kernel,
Arnd Bergmann
In-Reply-To: <20190325053456.14599-5-alastair@au1.ibm.com>
On 25/3/19 4:34 pm, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Remove some unused exported symbols.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> ---
> drivers/misc/ocxl/config.c | 4 +---
> drivers/misc/ocxl/ocxl_internal.h | 23 +++++++++++++++++++++++
> include/misc/ocxl.h | 23 -----------------------
> 3 files changed, 24 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
> index 4dc11897237d..5e65acb8e134 100644
> --- a/drivers/misc/ocxl/config.c
> +++ b/drivers/misc/ocxl/config.c
> @@ -2,8 +2,8 @@
> // Copyright 2017 IBM Corp.
> #include <linux/pci.h>
> #include <asm/pnv-ocxl.h>
> -#include <misc/ocxl.h>
> #include <misc/ocxl-config.h>
> +#include "ocxl_internal.h"
>
> #define EXTRACT_BIT(val, bit) (!!(val & BIT(bit)))
> #define EXTRACT_BITS(val, s, e) ((val & GENMASK(e, s)) >> s)
> @@ -299,7 +299,6 @@ int ocxl_config_check_afu_index(struct pci_dev *dev,
> }
> return 1;
> }
> -EXPORT_SYMBOL_GPL(ocxl_config_check_afu_index);
>
> static int read_afu_name(struct pci_dev *dev, struct ocxl_fn_config *fn,
> struct ocxl_afu_config *afu)
> @@ -535,7 +534,6 @@ int ocxl_config_get_pasid_info(struct pci_dev *dev, int *count)
> {
> return pnv_ocxl_get_pasid_count(dev, count);
> }
> -EXPORT_SYMBOL_GPL(ocxl_config_get_pasid_info);
>
> void ocxl_config_set_afu_pasid(struct pci_dev *dev, int pos, int pasid_base,
> u32 pasid_count_log)
> diff --git a/drivers/misc/ocxl/ocxl_internal.h b/drivers/misc/ocxl/ocxl_internal.h
> index 321b29e77f45..06fd98c989c8 100644
> --- a/drivers/misc/ocxl/ocxl_internal.h
> +++ b/drivers/misc/ocxl/ocxl_internal.h
> @@ -107,6 +107,29 @@ void ocxl_pasid_afu_free(struct ocxl_fn *fn, u32 start, u32 size);
> int ocxl_actag_afu_alloc(struct ocxl_fn *fn, u32 size);
> void ocxl_actag_afu_free(struct ocxl_fn *fn, u32 start, u32 size);
>
> +/*
> + * Get the max PASID value that can be used by the function
> + */
> +int ocxl_config_get_pasid_info(struct pci_dev *dev, int *count);
> +
> +/*
> + * Check if an AFU index is valid for the given function.
> + *
> + * AFU indexes can be sparse, so a driver should check all indexes up
> + * to the maximum found in the function description
> + */
> +int ocxl_config_check_afu_index(struct pci_dev *dev,
> + struct ocxl_fn_config *fn, int afu_idx);
> +
> +/**
> + * Update values within a Process Element
> + *
> + * link_handle: the link handle associated with the process element
> + * pasid: the PASID for the AFU context
> + * tid: the new thread id for the process element
> + */
> +int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
> +
> struct ocxl_context *ocxl_context_alloc(void);
> int ocxl_context_init(struct ocxl_context *ctx, struct ocxl_afu *afu,
> struct address_space *mapping);
> diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
> index 4544573cc93c..9530d3be1b30 100644
> --- a/include/misc/ocxl.h
> +++ b/include/misc/ocxl.h
> @@ -56,15 +56,6 @@ struct ocxl_fn_config {
> int ocxl_config_read_function(struct pci_dev *dev,
> struct ocxl_fn_config *fn);
>
> -/*
> - * Check if an AFU index is valid for the given function.
> - *
> - * AFU indexes can be sparse, so a driver should check all indexes up
> - * to the maximum found in the function description
> - */
> -int ocxl_config_check_afu_index(struct pci_dev *dev,
> - struct ocxl_fn_config *fn, int afu_idx);
> -
> /*
> * Read the configuration space of a function for the AFU specified by
> * the index 'afu_idx'. Fills in a ocxl_afu_config structure
> @@ -74,11 +65,6 @@ int ocxl_config_read_afu(struct pci_dev *dev,
> struct ocxl_afu_config *afu,
> u8 afu_idx);
>
> -/*
> - * Get the max PASID value that can be used by the function
> - */
> -int ocxl_config_get_pasid_info(struct pci_dev *dev, int *count);
> -
> /*
> * Tell an AFU, by writing in the configuration space, the PASIDs that
> * it can use. Range starts at 'pasid_base' and its size is a multiple
> @@ -188,15 +174,6 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
> void (*xsl_err_cb)(void *data, u64 addr, u64 dsisr),
> void *xsl_err_data);
>
> -/**
> - * Update values within a Process Element
> - *
> - * link_handle: the link handle associated with the process element
> - * pasid: the PASID for the AFU context
> - * tid: the new thread id for the process element
> - */
> -int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
> -
> /*
> * Remove a Process Element from the Shared Process Area for a link
> */
>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH v4 3/4] ocxl: Remove superfluous 'extern' from headers
From: Andrew Donnellan @ 2019-04-05 7:09 UTC (permalink / raw)
To: Alastair D'Silva, alastair
Cc: Frederic Barrat, Greg Kroah-Hartman, linuxppc-dev, linux-kernel,
Arnd Bergmann
In-Reply-To: <20190325053456.14599-4-alastair@au1.ibm.com>
On 25/3/19 4:34 pm, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> The 'extern' keyword adds no value here.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> ---
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> drivers/misc/ocxl/ocxl_internal.h | 54 +++++++++++++++----------------
> include/misc/ocxl.h | 36 ++++++++++-----------
> 2 files changed, 44 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/misc/ocxl/ocxl_internal.h b/drivers/misc/ocxl/ocxl_internal.h
> index a32f2151029f..321b29e77f45 100644
> --- a/drivers/misc/ocxl/ocxl_internal.h
> +++ b/drivers/misc/ocxl/ocxl_internal.h
> @@ -16,7 +16,6 @@
>
> extern struct pci_driver ocxl_pci_driver;
>
> -
> struct ocxl_fn {
> struct device dev;
> int bar_used[3];
> @@ -92,41 +91,40 @@ struct ocxl_process_element {
> __be32 software_state;
> };
>
> +struct ocxl_afu *ocxl_afu_get(struct ocxl_afu *afu);
> +void ocxl_afu_put(struct ocxl_afu *afu);
>
> -extern struct ocxl_afu *ocxl_afu_get(struct ocxl_afu *afu);
> -extern void ocxl_afu_put(struct ocxl_afu *afu);
> -
> -extern int ocxl_create_cdev(struct ocxl_afu *afu);
> -extern void ocxl_destroy_cdev(struct ocxl_afu *afu);
> -extern int ocxl_register_afu(struct ocxl_afu *afu);
> -extern void ocxl_unregister_afu(struct ocxl_afu *afu);
> +int ocxl_create_cdev(struct ocxl_afu *afu);
> +void ocxl_destroy_cdev(struct ocxl_afu *afu);
> +int ocxl_register_afu(struct ocxl_afu *afu);
> +void ocxl_unregister_afu(struct ocxl_afu *afu);
>
> -extern int ocxl_file_init(void);
> -extern void ocxl_file_exit(void);
> +int ocxl_file_init(void);
> +void ocxl_file_exit(void);
>
> -extern int ocxl_pasid_afu_alloc(struct ocxl_fn *fn, u32 size);
> -extern void ocxl_pasid_afu_free(struct ocxl_fn *fn, u32 start, u32 size);
> -extern int ocxl_actag_afu_alloc(struct ocxl_fn *fn, u32 size);
> -extern void ocxl_actag_afu_free(struct ocxl_fn *fn, u32 start, u32 size);
> +int ocxl_pasid_afu_alloc(struct ocxl_fn *fn, u32 size);
> +void ocxl_pasid_afu_free(struct ocxl_fn *fn, u32 start, u32 size);
> +int ocxl_actag_afu_alloc(struct ocxl_fn *fn, u32 size);
> +void ocxl_actag_afu_free(struct ocxl_fn *fn, u32 start, u32 size);
>
> -extern struct ocxl_context *ocxl_context_alloc(void);
> -extern int ocxl_context_init(struct ocxl_context *ctx, struct ocxl_afu *afu,
> +struct ocxl_context *ocxl_context_alloc(void);
> +int ocxl_context_init(struct ocxl_context *ctx, struct ocxl_afu *afu,
> struct address_space *mapping);
> -extern int ocxl_context_attach(struct ocxl_context *ctx, u64 amr);
> -extern int ocxl_context_mmap(struct ocxl_context *ctx,
> +int ocxl_context_attach(struct ocxl_context *ctx, u64 amr);
> +int ocxl_context_mmap(struct ocxl_context *ctx,
> struct vm_area_struct *vma);
> -extern int ocxl_context_detach(struct ocxl_context *ctx);
> -extern void ocxl_context_detach_all(struct ocxl_afu *afu);
> -extern void ocxl_context_free(struct ocxl_context *ctx);
> +int ocxl_context_detach(struct ocxl_context *ctx);
> +void ocxl_context_detach_all(struct ocxl_afu *afu);
> +void ocxl_context_free(struct ocxl_context *ctx);
>
> -extern int ocxl_sysfs_add_afu(struct ocxl_afu *afu);
> -extern void ocxl_sysfs_remove_afu(struct ocxl_afu *afu);
> +int ocxl_sysfs_add_afu(struct ocxl_afu *afu);
> +void ocxl_sysfs_remove_afu(struct ocxl_afu *afu);
>
> -extern int ocxl_afu_irq_alloc(struct ocxl_context *ctx, u64 *irq_offset);
> -extern int ocxl_afu_irq_free(struct ocxl_context *ctx, u64 irq_offset);
> -extern void ocxl_afu_irq_free_all(struct ocxl_context *ctx);
> -extern int ocxl_afu_irq_set_fd(struct ocxl_context *ctx, u64 irq_offset,
> +int ocxl_afu_irq_alloc(struct ocxl_context *ctx, u64 *irq_offset);
> +int ocxl_afu_irq_free(struct ocxl_context *ctx, u64 irq_offset);
> +void ocxl_afu_irq_free_all(struct ocxl_context *ctx);
> +int ocxl_afu_irq_set_fd(struct ocxl_context *ctx, u64 irq_offset,
> int eventfd);
> -extern u64 ocxl_afu_irq_get_addr(struct ocxl_context *ctx, u64 irq_offset);
> +u64 ocxl_afu_irq_get_addr(struct ocxl_context *ctx, u64 irq_offset);
>
> #endif /* _OCXL_INTERNAL_H_ */
> diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
> index 9ff6ddc28e22..4544573cc93c 100644
> --- a/include/misc/ocxl.h
> +++ b/include/misc/ocxl.h
> @@ -53,7 +53,7 @@ struct ocxl_fn_config {
> * Read the configuration space of a function and fill in a
> * ocxl_fn_config structure with all the function details
> */
> -extern int ocxl_config_read_function(struct pci_dev *dev,
> +int ocxl_config_read_function(struct pci_dev *dev,
> struct ocxl_fn_config *fn);
>
> /*
> @@ -62,14 +62,14 @@ extern int ocxl_config_read_function(struct pci_dev *dev,
> * AFU indexes can be sparse, so a driver should check all indexes up
> * to the maximum found in the function description
> */
> -extern int ocxl_config_check_afu_index(struct pci_dev *dev,
> +int ocxl_config_check_afu_index(struct pci_dev *dev,
> struct ocxl_fn_config *fn, int afu_idx);
>
> /*
> * Read the configuration space of a function for the AFU specified by
> * the index 'afu_idx'. Fills in a ocxl_afu_config structure
> */
> -extern int ocxl_config_read_afu(struct pci_dev *dev,
> +int ocxl_config_read_afu(struct pci_dev *dev,
> struct ocxl_fn_config *fn,
> struct ocxl_afu_config *afu,
> u8 afu_idx);
> @@ -77,7 +77,7 @@ extern int ocxl_config_read_afu(struct pci_dev *dev,
> /*
> * Get the max PASID value that can be used by the function
> */
> -extern int ocxl_config_get_pasid_info(struct pci_dev *dev, int *count);
> +int ocxl_config_get_pasid_info(struct pci_dev *dev, int *count);
>
> /*
> * Tell an AFU, by writing in the configuration space, the PASIDs that
> @@ -87,7 +87,7 @@ extern int ocxl_config_get_pasid_info(struct pci_dev *dev, int *count);
> * 'afu_control_offset' is the offset of the AFU control DVSEC which
> * can be found in the function configuration
> */
> -extern void ocxl_config_set_afu_pasid(struct pci_dev *dev,
> +void ocxl_config_set_afu_pasid(struct pci_dev *dev,
> int afu_control_offset,
> int pasid_base, u32 pasid_count_log);
>
> @@ -98,7 +98,7 @@ extern void ocxl_config_set_afu_pasid(struct pci_dev *dev,
> * 'supported' is the total number of actags desired by all the AFUs
> * of the function.
> */
> -extern int ocxl_config_get_actag_info(struct pci_dev *dev,
> +int ocxl_config_get_actag_info(struct pci_dev *dev,
> u16 *base, u16 *enabled, u16 *supported);
>
> /*
> @@ -108,7 +108,7 @@ extern int ocxl_config_get_actag_info(struct pci_dev *dev,
> * 'func_offset' is the offset of the Function DVSEC that can found in
> * the function configuration
> */
> -extern void ocxl_config_set_actag(struct pci_dev *dev, int func_offset,
> +void ocxl_config_set_actag(struct pci_dev *dev, int func_offset,
> u32 actag_base, u32 actag_count);
>
> /*
> @@ -118,7 +118,7 @@ extern void ocxl_config_set_actag(struct pci_dev *dev, int func_offset,
> * 'afu_control_offset' is the offset of the AFU control DVSEC for the
> * desired AFU. It can be found in the AFU configuration
> */
> -extern void ocxl_config_set_afu_actag(struct pci_dev *dev,
> +void ocxl_config_set_afu_actag(struct pci_dev *dev,
> int afu_control_offset,
> int actag_base, int actag_count);
>
> @@ -128,7 +128,7 @@ extern void ocxl_config_set_afu_actag(struct pci_dev *dev,
> * 'afu_control_offset' is the offset of the AFU control DVSEC for the
> * desired AFU. It can be found in the AFU configuration
> */
> -extern void ocxl_config_set_afu_state(struct pci_dev *dev,
> +void ocxl_config_set_afu_state(struct pci_dev *dev,
> int afu_control_offset, int enable);
>
> /*
> @@ -139,7 +139,7 @@ extern void ocxl_config_set_afu_state(struct pci_dev *dev,
> * between the host and device, and set the Transaction Layer on both
> * accordingly.
> */
> -extern int ocxl_config_set_TL(struct pci_dev *dev, int tl_dvsec);
> +int ocxl_config_set_TL(struct pci_dev *dev, int tl_dvsec);
>
> /*
> * Request an AFU to terminate a PASID.
> @@ -152,7 +152,7 @@ extern int ocxl_config_set_TL(struct pci_dev *dev, int tl_dvsec);
> * 'afu_control_offset' is the offset of the AFU control DVSEC for the
> * desired AFU. It can be found in the AFU configuration
> */
> -extern int ocxl_config_terminate_pasid(struct pci_dev *dev,
> +int ocxl_config_terminate_pasid(struct pci_dev *dev,
> int afu_control_offset, int pasid);
>
> /*
> @@ -165,13 +165,13 @@ extern int ocxl_config_terminate_pasid(struct pci_dev *dev,
> * Returns a 'link handle' that should be used for further calls for
> * the link
> */
> -extern int ocxl_link_setup(struct pci_dev *dev, int PE_mask,
> +int ocxl_link_setup(struct pci_dev *dev, int PE_mask,
> void **link_handle);
>
> /*
> * Remove the association between the function and its link.
> */
> -extern void ocxl_link_release(struct pci_dev *dev, void *link_handle);
> +void ocxl_link_release(struct pci_dev *dev, void *link_handle);
>
> /*
> * Add a Process Element to the Shared Process Area for a link.
> @@ -183,7 +183,7 @@ extern void ocxl_link_release(struct pci_dev *dev, void *link_handle);
> * 'xsl_err_data' is an argument passed to the above callback, if
> * defined
> */
> -extern int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
> +int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
> u64 amr, struct mm_struct *mm,
> void (*xsl_err_cb)(void *data, u64 addr, u64 dsisr),
> void *xsl_err_data);
> @@ -195,12 +195,12 @@ extern int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
> * pasid: the PASID for the AFU context
> * tid: the new thread id for the process element
> */
> -extern int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
> +int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
>
> /*
> * Remove a Process Element from the Shared Process Area for a link
> */
> -extern int ocxl_link_remove_pe(void *link_handle, int pasid);
> +int ocxl_link_remove_pe(void *link_handle, int pasid);
>
> /*
> * Allocate an AFU interrupt associated to the link.
> @@ -212,12 +212,12 @@ extern int ocxl_link_remove_pe(void *link_handle, int pasid);
> * interrupt. It is an MMIO address which needs to be remapped (one
> * page).
> */
> -extern int ocxl_link_irq_alloc(void *link_handle, int *hw_irq,
> +int ocxl_link_irq_alloc(void *link_handle, int *hw_irq,
> u64 *obj_handle);
>
> /*
> * Free a previously allocated AFU interrupt
> */
> -extern void ocxl_link_free_irq(void *link_handle, int hw_irq);
> +void ocxl_link_free_irq(void *link_handle, int hw_irq);
>
> #endif /* _MISC_OCXL_H_ */
>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH v4 2/4] ocxl: read_pasid never returns an error, so make it void
From: Andrew Donnellan @ 2019-04-05 7:05 UTC (permalink / raw)
To: Alastair D'Silva, alastair
Cc: Arnd Bergmann, Greg Kroah-Hartman, Greg Kurz, linux-kernel,
Frederic Barrat, linuxppc-dev
In-Reply-To: <20190325053456.14599-3-alastair@au1.ibm.com>
On 25/3/19 4:34 pm, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> No need for a return value in read_pasid as it only returns 0.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> Reviewed-by: Greg Kurz <groug@kaod.org>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> ---
> drivers/misc/ocxl/config.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
> index 8f2c5d8bd2ee..4dc11897237d 100644
> --- a/drivers/misc/ocxl/config.c
> +++ b/drivers/misc/ocxl/config.c
> @@ -68,7 +68,7 @@ static int find_dvsec_afu_ctrl(struct pci_dev *dev, u8 afu_idx)
> return 0;
> }
>
> -static int read_pasid(struct pci_dev *dev, struct ocxl_fn_config *fn)
> +static void read_pasid(struct pci_dev *dev, struct ocxl_fn_config *fn)
> {
> u16 val;
> int pos;
> @@ -89,7 +89,6 @@ static int read_pasid(struct pci_dev *dev, struct ocxl_fn_config *fn)
> out:
> dev_dbg(&dev->dev, "PASID capability:\n");
> dev_dbg(&dev->dev, " Max PASID log = %d\n", fn->max_pasid_log);
> - return 0;
> }
>
> static int read_dvsec_tl(struct pci_dev *dev, struct ocxl_fn_config *fn)
> @@ -205,11 +204,7 @@ int ocxl_config_read_function(struct pci_dev *dev, struct ocxl_fn_config *fn)
> {
> int rc;
>
> - rc = read_pasid(dev, fn);
> - if (rc) {
> - dev_err(&dev->dev, "Invalid PASID configuration: %d\n", rc);
> - return -ENODEV;
> - }
> + read_pasid(dev, fn);
>
> rc = read_dvsec_tl(dev, fn);
> if (rc) {
>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH v4 1/4] ocxl: Rename struct link to ocxl_link
From: Andrew Donnellan @ 2019-04-05 7:05 UTC (permalink / raw)
To: Alastair D'Silva, alastair
Cc: Arnd Bergmann, Greg Kroah-Hartman, Greg Kurz, linux-kernel,
Frederic Barrat, linuxppc-dev
In-Reply-To: <20190325053456.14599-2-alastair@au1.ibm.com>
On 25/3/19 4:34 pm, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> The term 'link' is ambiguous (especially when the struct is used for a
> list), so rename it for clarity.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> Reviewed-by: Greg Kurz <groug@kaod.org>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> ---
> drivers/misc/ocxl/file.c | 5 ++---
> drivers/misc/ocxl/link.c | 36 ++++++++++++++++++------------------
> 2 files changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
> index e6a607488f8a..009e09b7ded5 100644
> --- a/drivers/misc/ocxl/file.c
> +++ b/drivers/misc/ocxl/file.c
> @@ -151,10 +151,9 @@ static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx,
> mutex_unlock(&ctx->status_mutex);
>
> if (status == ATTACHED) {
> - int rc;
> - struct link *link = ctx->afu->fn->link;
> + int rc = ocxl_link_update_pe(ctx->afu->fn->link,
> + ctx->pasid, ctx->tidr);
>
> - rc = ocxl_link_update_pe(link, ctx->pasid, ctx->tidr);
> if (rc)
> return rc;
> }
> diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
> index d50b861d7e57..8d2690a1a9de 100644
> --- a/drivers/misc/ocxl/link.c
> +++ b/drivers/misc/ocxl/link.c
> @@ -76,7 +76,7 @@ struct spa {
> * limited number of opencapi slots on a system and lookup is only
> * done when the device is probed
> */
> -struct link {
> +struct ocxl_link {
> struct list_head list;
> struct kref ref;
> int domain;
> @@ -179,7 +179,7 @@ static void xsl_fault_handler_bh(struct work_struct *fault_work)
>
> static irqreturn_t xsl_fault_handler(int irq, void *data)
> {
> - struct link *link = (struct link *) data;
> + struct ocxl_link *link = (struct ocxl_link *) data;
> struct spa *spa = link->spa;
> u64 dsisr, dar, pe_handle;
> struct pe_data *pe_data;
> @@ -256,7 +256,7 @@ static int map_irq_registers(struct pci_dev *dev, struct spa *spa)
> &spa->reg_tfc, &spa->reg_pe_handle);
> }
>
> -static int setup_xsl_irq(struct pci_dev *dev, struct link *link)
> +static int setup_xsl_irq(struct pci_dev *dev, struct ocxl_link *link)
> {
> struct spa *spa = link->spa;
> int rc;
> @@ -311,7 +311,7 @@ static int setup_xsl_irq(struct pci_dev *dev, struct link *link)
> return rc;
> }
>
> -static void release_xsl_irq(struct link *link)
> +static void release_xsl_irq(struct ocxl_link *link)
> {
> struct spa *spa = link->spa;
>
> @@ -323,7 +323,7 @@ static void release_xsl_irq(struct link *link)
> unmap_irq_registers(spa);
> }
>
> -static int alloc_spa(struct pci_dev *dev, struct link *link)
> +static int alloc_spa(struct pci_dev *dev, struct ocxl_link *link)
> {
> struct spa *spa;
>
> @@ -350,7 +350,7 @@ static int alloc_spa(struct pci_dev *dev, struct link *link)
> return 0;
> }
>
> -static void free_spa(struct link *link)
> +static void free_spa(struct ocxl_link *link)
> {
> struct spa *spa = link->spa;
>
> @@ -364,12 +364,12 @@ static void free_spa(struct link *link)
> }
> }
>
> -static int alloc_link(struct pci_dev *dev, int PE_mask, struct link **out_link)
> +static int alloc_link(struct pci_dev *dev, int PE_mask, struct ocxl_link **out_link)
> {
> - struct link *link;
> + struct ocxl_link *link;
> int rc;
>
> - link = kzalloc(sizeof(struct link), GFP_KERNEL);
> + link = kzalloc(sizeof(struct ocxl_link), GFP_KERNEL);
> if (!link)
> return -ENOMEM;
>
> @@ -405,7 +405,7 @@ static int alloc_link(struct pci_dev *dev, int PE_mask, struct link **out_link)
> return rc;
> }
>
> -static void free_link(struct link *link)
> +static void free_link(struct ocxl_link *link)
> {
> release_xsl_irq(link);
> free_spa(link);
> @@ -415,7 +415,7 @@ static void free_link(struct link *link)
> int ocxl_link_setup(struct pci_dev *dev, int PE_mask, void **link_handle)
> {
> int rc = 0;
> - struct link *link;
> + struct ocxl_link *link;
>
> mutex_lock(&links_list_lock);
> list_for_each_entry(link, &links_list, list) {
> @@ -442,7 +442,7 @@ EXPORT_SYMBOL_GPL(ocxl_link_setup);
>
> static void release_xsl(struct kref *ref)
> {
> - struct link *link = container_of(ref, struct link, ref);
> + struct ocxl_link *link = container_of(ref, struct ocxl_link, ref);
>
> list_del(&link->list);
> /* call platform code before releasing data */
> @@ -452,7 +452,7 @@ static void release_xsl(struct kref *ref)
>
> void ocxl_link_release(struct pci_dev *dev, void *link_handle)
> {
> - struct link *link = (struct link *) link_handle;
> + struct ocxl_link *link = (struct ocxl_link *) link_handle;
>
> mutex_lock(&links_list_lock);
> kref_put(&link->ref, release_xsl);
> @@ -488,7 +488,7 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
> void (*xsl_err_cb)(void *data, u64 addr, u64 dsisr),
> void *xsl_err_data)
> {
> - struct link *link = (struct link *) link_handle;
> + struct ocxl_link *link = (struct ocxl_link *) link_handle;
> struct spa *spa = link->spa;
> struct ocxl_process_element *pe;
> int pe_handle, rc = 0;
> @@ -558,7 +558,7 @@ EXPORT_SYMBOL_GPL(ocxl_link_add_pe);
>
> int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid)
> {
> - struct link *link = (struct link *) link_handle;
> + struct ocxl_link *link = (struct ocxl_link *) link_handle;
> struct spa *spa = link->spa;
> struct ocxl_process_element *pe;
> int pe_handle, rc;
> @@ -594,7 +594,7 @@ int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid)
>
> int ocxl_link_remove_pe(void *link_handle, int pasid)
> {
> - struct link *link = (struct link *) link_handle;
> + struct ocxl_link *link = (struct ocxl_link *) link_handle;
> struct spa *spa = link->spa;
> struct ocxl_process_element *pe;
> struct pe_data *pe_data;
> @@ -666,7 +666,7 @@ EXPORT_SYMBOL_GPL(ocxl_link_remove_pe);
>
> int ocxl_link_irq_alloc(void *link_handle, int *hw_irq, u64 *trigger_addr)
> {
> - struct link *link = (struct link *) link_handle;
> + struct ocxl_link *link = (struct ocxl_link *) link_handle;
> int rc, irq;
> u64 addr;
>
> @@ -687,7 +687,7 @@ EXPORT_SYMBOL_GPL(ocxl_link_irq_alloc);
>
> void ocxl_link_free_irq(void *link_handle, int hw_irq)
> {
> - struct link *link = (struct link *) link_handle;
> + struct ocxl_link *link = (struct ocxl_link *) link_handle;
>
> pnv_ocxl_free_xive_irq(hw_irq);
> atomic_inc(&link->irq_available);
>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Applied "ASoC: fsl_esai: Support synchronous mode" to the asoc tree
From: Mark Brown @ 2019-04-05 3:26 UTC (permalink / raw)
To: S.j. Wang
Cc: alsa-devel, timur@kernel.org, Xiubo.Lee@gmail.com,
linuxppc-dev@lists.ozlabs.org, Shengjiu Wang,
nicoleotsuka@gmail.com, broonie@kernel.org, festevam@gmail.com
In-Reply-To: <a24d5493c392d39aefc6239e3dd97f9dd5fff1a1.1554370750.git.shengjiu.wang@nxp.com>
The patch
ASoC: fsl_esai: Support synchronous mode
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 1997ee89f36da906efb8e700f1d08368c73883be Mon Sep 17 00:00:00 2001
From: "S.j. Wang" <shengjiu.wang@nxp.com>
Date: Thu, 4 Apr 2019 09:40:56 +0000
Subject: [PATCH] ASoC: fsl_esai: Support synchronous mode
In ESAI synchronous mode, the clock is generated by Tx, So
we should always set registers of Tx which relate with the
bit clock and frame clock generation (TCCR, TCR, ECR), even
there is only Rx is working.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/fsl/fsl_esai.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 3623aa9a6f2e..c7410bbfd2af 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -218,7 +218,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id,
{
struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
struct clk *clksrc = esai_priv->extalclk;
- bool tx = clk_id <= ESAI_HCKT_EXTAL;
+ bool tx = (clk_id <= ESAI_HCKT_EXTAL || esai_priv->synchronous);
bool in = dir == SND_SOC_CLOCK_IN;
u32 ratio, ecr = 0;
unsigned long clk_rate;
@@ -253,7 +253,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id,
ecr |= ESAI_ECR_ETI;
/* fall through */
case ESAI_HCKR_EXTAL:
- ecr |= ESAI_ECR_ERI;
+ ecr |= esai_priv->synchronous ? ESAI_ECR_ETI : ESAI_ECR_ERI;
break;
default:
return -EINVAL;
@@ -537,10 +537,18 @@ static int fsl_esai_hw_params(struct snd_pcm_substream *substream,
bclk = params_rate(params) * slot_width * esai_priv->slots;
- ret = fsl_esai_set_bclk(dai, tx, bclk);
+ ret = fsl_esai_set_bclk(dai, esai_priv->synchronous || tx, bclk);
if (ret)
return ret;
+ mask = ESAI_xCR_xSWS_MASK;
+ val = ESAI_xCR_xSWS(slot_width, width);
+
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask, val);
+ /* Recording in synchronous mode needs to set TCR also */
+ if (!tx && esai_priv->synchronous)
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, mask, val);
+
/* Use Normal mode to support monaural audio */
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
ESAI_xCR_xMOD_MASK, params_channels(params) > 1 ?
@@ -556,10 +564,9 @@ static int fsl_esai_hw_params(struct snd_pcm_substream *substream,
regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx), mask, val);
- mask = ESAI_xCR_xSWS_MASK | (tx ? ESAI_xCR_PADC : 0);
- val = ESAI_xCR_xSWS(slot_width, width) | (tx ? ESAI_xCR_PADC : 0);
-
- regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask, val);
+ if (tx)
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
+ ESAI_xCR_PADC, ESAI_xCR_PADC);
/* Remove ESAI personal reset by configuring ESAI_PCRC and ESAI_PRRC */
regmap_update_bits(esai_priv->regmap, REG_ESAI_PRRC,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH -next] ibmvnic: remove set but not used variable 'netdev'
From: David Miller @ 2019-04-05 0:37 UTC (permalink / raw)
To: yuehaibing; +Cc: linux-kernel, tlfalcon, netdev, paulus, jallen, linuxppc-dev
In-Reply-To: <20190403075409.29384-1-yuehaibing@huawei.com>
From: Yue Haibing <yuehaibing@huawei.com>
Date: Wed, 3 Apr 2019 15:54:09 +0800
> From: YueHaibing <yuehaibing@huawei.com>
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/ibm/ibmvnic.c: In function '__ibmvnic_reset':
> drivers/net/ethernet/ibm/ibmvnic.c:1971:21: warning: variable 'netdev' set but not used [-Wunused-but-set-variable]
>
> It's never used since introduction in
> commit ed651a10875f ("ibmvnic: Updated reset handling")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH kernel RFC 2/2] vfio-pci-nvlink2: Implement interconnect isolation
From: David Gibson @ 2019-04-05 0:34 UTC (permalink / raw)
To: Alex Williamson
Cc: Jose Ricardo Ziviani, Alexey Kardashevskiy,
Daniel Henrique Barboza, kvm-ppc, Piotr Jaroszynski,
Leonardo Augusto Guimarães Garcia, linuxppc-dev
In-Reply-To: <20190322171025.64bc328c@x1.home>
[-- Attachment #1: Type: text/plain, Size: 23007 bytes --]
On Fri, Mar 22, 2019 at 05:10:25PM -0600, Alex Williamson wrote:
> On Fri, 22 Mar 2019 14:08:38 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Thu, Mar 21, 2019 at 12:19:34PM -0600, Alex Williamson wrote:
> > > On Thu, 21 Mar 2019 10:56:00 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >
> > > > On Wed, Mar 20, 2019 at 01:09:08PM -0600, Alex Williamson wrote:
> > > > > On Wed, 20 Mar 2019 15:38:24 +1100
> > > > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > > > >
> > > > > > On Tue, Mar 19, 2019 at 10:36:19AM -0600, Alex Williamson wrote:
> > > > > > > On Fri, 15 Mar 2019 19:18:35 +1100
> > > > > > > Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> > > > > > >
> > > > > > > > The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> > > > > > > > (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> > > > > > > > peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment the POWERNV
> > > > > > > > platform puts all interconnected GPUs to the same IOMMU group.
> > > > > > > >
> > > > > > > > However the user may want to pass individual GPUs to the userspace so
> > > > > > > > in order to do so we need to put them into separate IOMMU groups and
> > > > > > > > cut off the interconnects.
> > > > > > > >
> > > > > > > > Thankfully V100 GPUs implement an interface to do by programming link
> > > > > > > > disabling mask to BAR0 of a GPU. Once a link is disabled in a GPU using
> > > > > > > > this interface, it cannot be re-enabled until the secondary bus reset is
> > > > > > > > issued to the GPU.
> > > > > > > >
> > > > > > > > This defines a reset_done() handler for V100 NVlink2 device which
> > > > > > > > determines what links need to be disabled. This relies on presence
> > > > > > > > of the new "ibm,nvlink-peers" device tree property of a GPU telling which
> > > > > > > > PCI peers it is connected to (which includes NVLink bridges or peer GPUs).
> > > > > > > >
> > > > > > > > This does not change the existing behaviour and instead adds
> > > > > > > > a new "isolate_nvlink" kernel parameter to allow such isolation.
> > > > > > > >
> > > > > > > > The alternative approaches would be:
> > > > > > > >
> > > > > > > > 1. do this in the system firmware (skiboot) but for that we would need
> > > > > > > > to tell skiboot via an additional OPAL call whether or not we want this
> > > > > > > > isolation - skiboot is unaware of IOMMU groups.
> > > > > > > >
> > > > > > > > 2. do this in the secondary bus reset handler in the POWERNV platform -
> > > > > > > > the problem with that is at that point the device is not enabled, i.e.
> > > > > > > > config space is not restored so we need to enable the device (i.e. MMIO
> > > > > > > > bit in CMD register + program valid address to BAR0) in order to disable
> > > > > > > > links and then perhaps undo all this initialization to bring the device
> > > > > > > > back to the state where pci_try_reset_function() expects it to be.
> > > > > > >
> > > > > > > The trouble seems to be that this approach only maintains the isolation
> > > > > > > exposed by the IOMMU group when vfio-pci is the active driver for the
> > > > > > > device. IOMMU groups can be used by any driver and the IOMMU core is
> > > > > > > incorporating groups in various ways.
> > > > > >
> > > > > > I don't think that reasoning is quite right. An IOMMU group doesn't
> > > > > > necessarily represent devices which *are* isolated, just devices which
> > > > > > *can be* isolated. There are plenty of instances when we don't need
> > > > > > to isolate devices in different IOMMU groups: passing both groups to
> > > > > > the same guest or userspace VFIO driver for example, or indeed when
> > > > > > both groups are owned by regular host kernel drivers.
> > > > > >
> > > > > > In at least some of those cases we also don't want to isolate the
> > > > > > devices when we don't have to, usually for performance reasons.
> > > > >
> > > > > I see IOMMU groups as representing the current isolation of the device,
> > > > > not just the possible isolation. If there are ways to break down that
> > > > > isolation then ideally the group would be updated to reflect it. The
> > > > > ACS disable patches seem to support this, at boot time we can choose to
> > > > > disable ACS at certain points in the topology to favor peer-to-peer
> > > > > performance over isolation. This is then reflected in the group
> > > > > composition, because even though ACS *can be* enabled at the given
> > > > > isolation points, it's intentionally not with this option. Whether or
> > > > > not a given user who owns multiple devices needs that isolation is
> > > > > really beside the point, the user can choose to connect groups via IOMMU
> > > > > mappings or reconfigure the system to disable ACS and potentially more
> > > > > direct routing. The IOMMU groups are still accurately reflecting the
> > > > > topology and IOMMU based isolation.
> > > >
> > > > Huh, ok, I think we need to straighten this out. Thinking of iommu
> > > > groups as possible rather than potential isolation was a conscious
> > >
> > > possible ~= potential
> >
> > Sorry, I meant "current" not "potential".
> >
> > > > decision on my part when we were first coming up with them. The
> > > > rationale was that that way iommu groups could be static for the
> > > > lifetime of boot, with more dynamic isolation state layered on top.
> > > >
> > > > Now, that was based on analogy with PAPR's concept of "Partitionable
> > > > Endpoints" which are decided by firmware before boot. However, I
> > > > think it makes sense in other contexts too: if iommu groups represent
> > > > current isolation, then we need some other way to advertise possible
> > > > isolation - otherwise how will the admin (and/or tools) know how it
> > > > can configure the iommu groups.
> > > >
> > > > VFIO already has the container, which represents explicitly a "group
> > > > of groups" that we don't care to isolate from each other. I don't
> > > > actually know what other uses of the iommu group infrastructure we
> > > > have at present and how they treat them.
> > >
> > > s/that we don't care to isolate/that the user doesn't care to isolate/
> >
> > Well, true, I guess we still want to isolate them when possible for
> > additional safety. But I don't think we should do so when that
> > isolation has a real performance cost, which it would in the case of
> > isolating linked GPUs here.
>
> I don't see that we can presume the user's intentions. This sounds
> like we're putting the kernel into the position of deciding policy.
It's not really a question of intentions. If two devices are in the
same container, then they are *not* isolated from the user's point of
view. Maybe they can't get at each other's MMIO, but they can clobber
each other's DMA inputs and outputs, and for many devices that will
include descriptor tables, allowing them to adversely affect each
others' behaviours.
> > > Though even that is not necessarily accurate, the container represents
> > > a shared IOMMU context, that context doesn't necessarily include
> > > mappings between devices, so the device can still be isolated *from
> > > each other*.
> >
> > Well, sure, but it's the only mechanism the user has for indicating
> > that they don't care about isolation between these device. That might
> > be because they simply don't care, but it might also be because they
> > want to use interlinks between those devices for additional
> > performance.
>
> Is a user really indicating "I don't care about isolation" by placing
> groups within the same container or just taking advantage of a shared
> IOMMU context? Again, we're presuming a policy decision that's never
> been defined in the API. It is possible to have both isolation and
> performance, for instance ACS includes a direct translated p2p feature
> that allows translated requests a direct path between devices, at least
> on the PCIe fabric (where supported by hardware).
>
> > > > So, if we now have dynamically reconfigurable groups which are a
> > > > departure from that design, how can we go from here trying to bring
> > > > things back to consistency.
> > >
> > > We don't currently have dynamically reconfigurable groups,
> >
> > Ah, ok. So what were these other use cases you were describing? Boot
> > time options which change how the iommu groups are generated? Or
> > something else.
>
> pci=option[,option...] [PCI] various PCI subsystem options.
>
> Some options herein operate on a specific device
> or a set of devices (<pci_dev>). These are
> specified in one of the following formats:
>
> [<domain>:]<bus>:<dev>.<func>[/<dev>.<func>]*
> pci:<vendor>:<device>[:<subvendor>:<subdevice>]
>
> ...
> disable_acs_redir=<pci_dev>[; ...]
> Specify one or more PCI devices (in the format
> specified above) separated by semicolons.
> Each device specified will have the PCI ACS
> redirect capabilities forced off which will
> allow P2P traffic between devices through
> bridges without forcing it upstream. Note:
> this removes isolation between devices and
> may put more devices in an IOMMU group.
>
> AIUI, GPU and RDMA were primary use cases for this. As noted, IOMMU
> groups take this into account since it's done at boot time and static,
> we're simply disabling isolation switches that would have otherwise
> been enabled at points in the topology (specifically enabling p2p as
> much as possible), and the IOMMU group grows to match.
Right. It's better than nothing, but requiring boot time
configuration is a pain. It'd be nice to have a way of runtime
configuring it. That will be much nicer to use if we can also runtime
introspect it, which requires some kind of two-level system
distinguishing current from possible isolation.
> The NVLink problem is rather the opposite of this, rather than simply
> disabling isolation for a sub-hierarchy and growing the IOMMU group, we
> need to enable isolation and then actively, and repeatedly maintain
> that configuration as it represents a finer granularity isolation
> promise to the system. And of course we're trying to manage the
> isolation of an interconnect for which we have no visibility.
Sigh. Yeah. That's pretty horrible.
> > > I think the
> > > question is how do we introduce dynamically configurable groups within
> > > the existing design, because whatever intentions were 7.5 years ago is
> > > rather irrelevant now.
> >
> > Well, yeah, I guess.
> >
> > > VFIO groups are mapped directly to IOMMU groups. IOMMU groups are the
> > > smallest set of devices which can be considered isolated from other
> > > sets of devices (not potentially, but as configured).
> >
> > Hm.. but what actually makes that assumption that this is the case as
> > configured, rather than just possibly - I'm taking "possible" to mean
> > possible with this host kernel, not just possible with this hardware.
>
> The IOMMU driver is ultimately responsible for deciding the isolation,
> but we have shared code that understands the PCI/e topology. That code
> looks at the actual, current ACS settings to decide the highest point
> in the topology where we might have p2p.
Right, but I was more thinking about the consumers of the information
than the producer.
> > > VFIO groups are
> > > the unit of ownership to userspace, therefore a VFIO group must be
> > > (currently) isolated from other groups.
> >
> > It must be currently isolated once the VFIO group is instantiated, but
> > is there actually anything that requires that current isolation before
> > the iommu group is instantiated as a vfio group.
>
> The iommu-core is incorporating more group-aware support, I believe
> default domains are group based and we might have per group reserved
> ranges, I'm not sure about that.
Hm, ok.
> > > The user owns and manages the
> > > IOMMU context for one or more groups via a container. A container
> > > allows efficiency in managing a shared IOVA space between groups.
> >
> > Yes, and it seems to me an obvious extension to have the container
> > also permit other efficiencies which aren't compatible with full
> > isolation.
>
> It might be a control point, yes, but I don't see that we can presume
> it.
Well, as above, I think the container already means the devices can't
really be considered isolated, even if they are in the limited sense
of can't touch each others MMIOs.
> If we were to automatically enable redirection within a container,
> we could wreak havoc on the IOVA space for the user.
Granted, am thinking more of the power case where the IOVA and MMIO
address ranges are well separated from each other anyway. Is there
any way we can set up the PCI address space on x86 to ensure that
regardless of group separation?
> ACS also
> theoretically provides a hardware path to enable this via direct
> translated p2p as well.
>
> > > > > > > So, if there's a device specific
> > > > > > > way to configure the isolation reported in the group, which requires
> > > > > > > some sort of active management against things like secondary bus
> > > > > > > resets, then I think we need to manage it above the attached endpoint
> > > > > > > driver.
> > > > > >
> > > > > > The problem is that above the endpoint driver, we don't actually have
> > > > > > enough information about what should be isolated. For VFIO we want to
> > > > > > isolate things if they're in different containers, for most regular
> > > > > > host kernel drivers we don't need to isolate at all (although we might
> > > > > > as well when it doesn't have a cost).
> > > > >
> > > > > This idea that we only want to isolate things if they're in different
> > > > > containers is bogus, imo. There are performance reasons why we might
> > > > > not want things isolated, but there are also address space reasons why
> > > > > we do. If there are direct routes between devices, the user needs to
> > > > > be aware of the IOVA pollution, if we maintain singleton groups, they
> > > > > don't. Granted we don't really account for this well in most
> > > > > userspaces and fumble through it by luck of the address space layout
> > > > > and lack of devices really attempting peer to peer access.
> > > >
> > > > I don't really follow what you're saying here.
> > >
> > > If the lack of isolation between devices includes peer-to-peer channels
> > > then the MMIO of the devices within the group pollutes the IOVA space
> > > of the container.
> >
> > Yes, if the permissible IOVA addresses overlap with valid MMIO
> > addresses. I don't really see why that's significant, though. We
> > already have basically the same situation if there are multiple
> > devices in a group. e.g. if you have several devices behind a dumb
> > PCI-E to PCI bridge, you can't actually prohibit peer-to-peer DMA
> > between them, and so those devices' MMIOs pollute the IOVA space for
> > each other, even if they don't for other devices in the container.
> > There's only so far we can go to prevent the user from shooting
> > themselves in the foot.
>
> So it's therefore OK to intentionally pollute the container IOVA
> space? I believe we'd like to think that hardware is headed towards
> being more isolation-aware and will evolve to the point where we have
> typically singleton group. Perhaps we'll also evolve to supporting ACS
> direct translated p2p so that we have both a pristine IOVA space and
> direct routes between devices. There are current issues with
> non-singleton groups that userspace doesn't handle (see "fumble
> through" comment above), but I'm not willing to say "this is
> userspace's problem anyway, therefore it's ok it make it worse".
>
> > > > > For in-kernel users, we're still theoretically trying to isolate
> > > > > devices such that they have restricted access to only the resources
> > > > > they need. Disabling things like ACS in the topology reduces that
> > > > > isolation. AFAICT, most users don't really care about that degree of
> > > > > isolation, so they run with iommu=pt for native driver performance
> > > > > while still having the IOMMU available for isolation use cases running
> > > > > in parallel. We don't currently have support for on-demand enabling
> > > > > isolation.
> > > >
> > > > Ok.
> > > >
> > > > > > The host side nVidia GPGPU
> > > > > > drivers also won't want to isolate the (host owned) NVLink devices
> > > > > > from each other, since they'll want to use the fast interconnects
> > > > >
> > > > > This falls into the same mixed use case scenario above where we don't
> > > > > really have a good solution today. Things like ACS are dynamically
> > > > > configurable, but we don't expose any interfaces to let drivers or
> > > > > users change it (aside from setpci, which we don't account for
> > > > > dynamically). We assume a simplistic model where if you want IOMMU,
> > > > > then you must also want the maximum configurable isolation.
> > > > > Dynamically changing routing is not necessarily the most foolproof
> > > > > thing either with potentially in-flight transactions and existing DMA
> > > > > mappings, which is why I've suggested a couple times that perhaps we
> > > > > could do a software hot-unplug of a sub-hierarchy, muck with isolation
> > > > > at the remaining node, then re-discover the removed devices.
> > > >
> > > > Ok, so I feel like we need to go fully one way or the other. Either:
> > > >
> > > > 1) Groups represent current isolation status, in which case we
> > > > deprecate vfio containers in favour of fusing groups beforehand,
> > > > and we need some new concept ("isolation atoms"?) to represent what
> > > > isolation is possible
> > >
> > > Nope, containers are owned by users and serve a purpose beyond what
> > > you're assuming here. Also, there's 7.5 years of userspace tooling
> > > broken by this. I do remember we had discussions about merging groups,
> > > but what we have now is what we agreed on.
> >
> > Well, quite - and I thought the reasoning that led to that design was
> > that groups would be a representation of isolation granularity, not
> > actual isolation. That allows them to be static, which as you say,
> > tools are likely to assume.
>
> What is the value of this idea of potential isolation? Any device
> might be considered potentially isolated, simply disable all the
> devices around it.
Well, assuming there's a disabling mechanism of suitable granularity.
> So now we have a "potentially isolated" group at
> each device. What have we accomplished? How do we build that into a
> user interface? Who decides where the actual isolation lines are
> drawn? Not that it didn't happen, but I don't recall this design idea
> and I don't see how it's practical.
The UI I had in mind is that this minimum granularity is what's
advertised to userspace. Again, this could vary with kernel
capabilities not just hardware capabilities - "theoretically
isolatable, but we haven't implemented that" counts as a single group.
When userspace wants to use some devices, it can choose whether to
grab them individually or to put several of its choice into a
"container" (analgous to a VFIO container, but could become a more
generic concept). Being in a container means the kernel should
prioritize performance over isolation. If the devices are widely
separated (e.g. separate PCI domains) that might not mean anything
much (beyond sharing a logical IOMMU AS), but if there's some sort of
fast-path between them, the kernel would enable it.
> > > > or
> > > >
> > > > 2) Groups represent potential isolation, with a higher level construct
> > > > representing current isolation. This could involve making vfio
> > > > containers essentially a wrapper around some more generic concept
> > > > ("isolation clusters"?) of a group of groups.
> > >
> > > Have fun. Containers and groups are exposed to userspace, so you're
> > > essentially suggesting to throw away all that support, for... I don't
> > > really know what.
> >
> > No, I'm not proposing removing containers, just changing them from
> > being purely VFIO specific to being the VFIO front end to a generic
> > concept. Roughly speaking VFIO containers would be to "isolation
> > clusters" (or whatever) as VFIO groups are to IOMMU groups now.
>
> Renaming everything doesn't help. AFAIK, there's nothing in vfio that
> prevents groups from being dynamic (changing them while in use might be
> unkind though), but they must be isolated from other groups. We can't
> move the line where we have isolation to anything above the group.
> Groups are currently not dynamic because "it's hard" (tm), but
> obviously it can be done with device removal and rediscovery.
>
> > > Groups are involved in IOMMU context, so dynamically
> > > changing what a group defines is hard.
> >
> > Absolutely! That's why I don't want to, and why my conception of
> > groups was defined so that they didn't have to.
>
> As above, groups are the unit of userspace ownership and therefore must
> be isolated.
>
> > > Thus my suggestions that mixed
> > > or dynamic workloads could make use of soft remove and rediscovery for
> > > sub-hierarchies, unbinding and rebinding drivers such that we have the
> > > proper expectations of DMA context. Thanks,
> >
> > Well, if we have to change groups, then that sounds like the sanest
> > available way to do it. But I'm not yet convinced that altering
> > groups makes sense rather than using a group-of-groups concept on top
> > of it - which would map to containers in the case of VFIO.
>
> Groups must be isolated in the vfio API. What happens underneath a
> group might be fungible, but the exposed group must be isolated.
Still not seeing what makes that an immutable law.
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH kernel v2] powerpc/powernv: Isolate NVLinks between GV100GL on Witherspoon
From: David Gibson @ 2019-04-04 23:56 UTC (permalink / raw)
To: Alex Williamson
Cc: Jose Ricardo Ziviani, kvm, Alexey Kardashevskiy,
Daniel Henrique Barboza, kvm-ppc, Sam Bobroff, Piotr Jaroszynski,
Leonardo Augusto Guimarães Garcia, linuxppc-dev
In-Reply-To: <20190404142225.371fe38a@x1.home>
[-- Attachment #1: Type: text/plain, Size: 10293 bytes --]
On Thu, Apr 04, 2019 at 02:22:25PM -0600, Alex Williamson wrote:
> On Thu, 4 Apr 2019 16:23:24 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>
> > The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> > (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> > peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment the POWERNV
> > platform puts all interconnected GPUs to the same IOMMU group.
> >
> > However the user may want to pass individual GPUs to the userspace so
> > in order to do so we need to put them into separate IOMMU groups and
> > cut off the interconnects.
> >
> > Thankfully V100 GPUs implement an interface to do by programming link
> > disabling mask to BAR0 of a GPU. Once a link is disabled in a GPU using
> > this interface, it cannot be re-enabled until the secondary bus reset is
> > issued to the GPU.
> >
> > This adds an extra step to the secondary bus reset handler (the one used
> > for such GPUs) to block NVLinks to GPUs which do not belong to the same
> > group as the GPU being reset.
> >
> > This adds a new "isolate_nvlink" kernel parameter to allow GPU isolation;
> > when enabled, every GPU gets its own IOMMU group. The new parameter is off
> > by default to preserve the existing behaviour.
> >
> > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > ---
> > Changes:
> > v2:
> > * this is rework of [PATCH kernel RFC 0/2] vfio, powerpc/powernv: Isolate GV100GL
> > but this time it is contained in the powernv platform
> > ---
> > arch/powerpc/platforms/powernv/Makefile | 2 +-
> > arch/powerpc/platforms/powernv/pci.h | 1 +
> > arch/powerpc/platforms/powernv/eeh-powernv.c | 1 +
> > arch/powerpc/platforms/powernv/npu-dma.c | 24 +++-
> > arch/powerpc/platforms/powernv/nvlinkgpu.c | 131 +++++++++++++++++++
> > 5 files changed, 156 insertions(+), 3 deletions(-)
> > create mode 100644 arch/powerpc/platforms/powernv/nvlinkgpu.c
> >
> > diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
> > index da2e99efbd04..60a10d3b36eb 100644
> > --- a/arch/powerpc/platforms/powernv/Makefile
> > +++ b/arch/powerpc/platforms/powernv/Makefile
> > @@ -6,7 +6,7 @@ obj-y += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
> > obj-y += opal-kmsg.o opal-powercap.o opal-psr.o opal-sensor-groups.o
> >
> > obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
> > -obj-$(CONFIG_PCI) += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
> > +obj-$(CONFIG_PCI) += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o nvlinkgpu.o
> > obj-$(CONFIG_CXL_BASE) += pci-cxl.o
> > obj-$(CONFIG_EEH) += eeh-powernv.o
> > obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
> > diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
> > index 8e36da379252..9fd3f391482c 100644
> > --- a/arch/powerpc/platforms/powernv/pci.h
> > +++ b/arch/powerpc/platforms/powernv/pci.h
> > @@ -250,5 +250,6 @@ extern void pnv_pci_unlink_table_and_group(struct iommu_table *tbl,
> > extern void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
> > void *tce_mem, u64 tce_size,
> > u64 dma_offset, unsigned int page_shift);
> > +extern void pnv_try_isolate_nvidia_v100(struct pci_dev *gpdev);
> >
> > #endif /* __POWERNV_PCI_H */
> > diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c b/arch/powerpc/platforms/powernv/eeh-powernv.c
> > index f38078976c5d..464b097d9635 100644
> > --- a/arch/powerpc/platforms/powernv/eeh-powernv.c
> > +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
> > @@ -937,6 +937,7 @@ void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
> > pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
> > pnv_eeh_bridge_reset(dev, EEH_RESET_DEACTIVATE);
> > }
> > + pnv_try_isolate_nvidia_v100(dev);
> > }
> >
> > static void pnv_eeh_wait_for_pending(struct pci_dn *pdn, const char *type,
> > diff --git a/arch/powerpc/platforms/powernv/npu-dma.c b/arch/powerpc/platforms/powernv/npu-dma.c
> > index dc23d9d2a7d9..017eae8197e7 100644
> > --- a/arch/powerpc/platforms/powernv/npu-dma.c
> > +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> > @@ -529,6 +529,23 @@ static void pnv_comp_attach_table_group(struct npu_comp *npucomp,
> > ++npucomp->pe_num;
> > }
> >
> > +static bool isolate_nvlink;
> > +
> > +static int __init parse_isolate_nvlink(char *p)
> > +{
> > + bool val;
> > +
> > + if (!p)
> > + val = true;
> > + else if (kstrtobool(p, &val))
> > + return -EINVAL;
> > +
> > + isolate_nvlink = val;
> > +
> > + return 0;
> > +}
> > +early_param("isolate_nvlink", parse_isolate_nvlink);
> > +
> > struct iommu_table_group *pnv_try_setup_npu_table_group(struct pnv_ioda_pe *pe)
> > {
> > struct iommu_table_group *table_group;
> > @@ -549,7 +566,7 @@ struct iommu_table_group *pnv_try_setup_npu_table_group(struct pnv_ioda_pe *pe)
> >
> > hose = pci_bus_to_host(npdev->bus);
> >
> > - if (hose->npu) {
> > + if (hose->npu && !isolate_nvlink) {
> > table_group = &hose->npu->npucomp.table_group;
> >
> > if (!table_group->group) {
> > @@ -559,7 +576,10 @@ struct iommu_table_group *pnv_try_setup_npu_table_group(struct pnv_ioda_pe *pe)
> > pe->pe_number);
> > }
> > } else {
> > - /* Create a group for 1 GPU and attached NPUs for POWER8 */
> > + /*
> > + * Create a group for 1 GPU and attached NPUs for
> > + * POWER8 (always) or POWER9 (when isolate_nvlink).
> > + */
> > pe->npucomp = kzalloc(sizeof(*pe->npucomp), GFP_KERNEL);
> > table_group = &pe->npucomp->table_group;
> > table_group->ops = &pnv_npu_peers_ops;
> > diff --git a/arch/powerpc/platforms/powernv/nvlinkgpu.c b/arch/powerpc/platforms/powernv/nvlinkgpu.c
> > new file mode 100644
> > index 000000000000..dbd8e9d47a05
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/powernv/nvlinkgpu.c
> > @@ -0,0 +1,131 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * A helper to disable NVLinks between GPUs on IBM Withersponn platform.
> > + *
> > + * Copyright (C) 2019 IBM Corp. All rights reserved.
> > + * Author: Alexey Kardashevskiy <aik@ozlabs.ru>
> > + *
> > + * 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.
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/device.h>
> > +#include <linux/of.h>
> > +#include <linux/iommu.h>
> > +#include <linux/pci.h>
> > +
> > +static int nvlinkgpu_is_ph_in_group(struct device *dev, void *data)
> > +{
> > + return dev->of_node->phandle == *(phandle *) data;
> > +}
> > +
> > +static u32 nvlinkgpu_get_disable_mask(struct device *dev)
> > +{
> > + int npu, peer;
> > + u32 mask;
> > + struct device_node *dn;
> > + struct iommu_group *group;
> > +
> > + dn = dev->of_node;
> > + if (!of_find_property(dn, "ibm,nvlink-peers", NULL))
> > + return 0;
> > +
> > + group = iommu_group_get(dev);
> > + if (!group)
> > + return 0;
> > +
> > + /*
> > + * Collect links to keep which includes links to NPU and links to
> > + * other GPUs in the same IOMMU group.
> > + */
> > + for (npu = 0, mask = 0; ; ++npu) {
> > + u32 npuph = 0;
> > +
> > + if (of_property_read_u32_index(dn, "ibm,npu", npu, &npuph))
> > + break;
> > +
> > + for (peer = 0; ; ++peer) {
> > + u32 peerph = 0;
> > +
> > + if (of_property_read_u32_index(dn, "ibm,nvlink-peers",
> > + peer, &peerph))
> > + break;
> > +
> > + if (peerph != npuph &&
> > + !iommu_group_for_each_dev(group, &peerph,
> > + nvlinkgpu_is_ph_in_group))
> > + continue;
> > +
> > + mask |= 1 << (peer + 16);
> > + }
> > + }
> > + iommu_group_put(group);
> > +
> > + /* Disabling mechanism takes links to disable so invert it here */
> > + mask = ~mask & 0x3F0000;
> > +
> > + return mask;
> > +}
> > +
> > +void pnv_try_isolate_nvidia_v100(struct pci_dev *bridge)
> > +{
> > + u32 mask;
> > + void __iomem *bar0_0, *bar0_120000, *bar0_a00000;
> > + struct pci_dev *pdev;
> > +
> > + if (!bridge->subordinate)
> > + return;
> > +
> > + pdev = list_first_entry_or_null(&bridge->subordinate->devices,
> > + struct pci_dev, bus_list);
> > + if (!pdev)
> > + return;
> > +
> > + if (pdev->vendor != PCI_VENDOR_ID_NVIDIA)
> > + return;
> > +
> > + mask = nvlinkgpu_get_disable_mask(&pdev->dev);
> > + if (!mask)
> > + return;
> > +
> > + bar0_0 = pci_iomap_range(pdev, 0, 0, 0x10000);
> > + bar0_120000 = pci_iomap_range(pdev, 0, 0x120000, 0x10000);
> > + bar0_a00000 = pci_iomap_range(pdev, 0, 0xA00000, 0x10000);
> > +
> > + if (bar0_120000 && bar0_0 && bar0_a00000) {
> > + u32 val;
> > + u16 cmd = 0, cmdmask = PCI_COMMAND_MEMORY;
> > +
> > + pci_restore_state(pdev);
> > + pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> > + if ((cmd & cmdmask) != cmdmask)
> > + pci_write_config_word(pdev, PCI_COMMAND, cmd | cmdmask);
> > +
> > + /*
> > + * The sequence is from "Tesla P100 and V100 SXM2 NVLink
> > + * Isolation on Multi-Tenant Systems".
> > + * The register names are not provided there either,
> > + * hence raw values.
> > + */
> > + iowrite32(0x4, bar0_120000 + 0x4C);
> > + iowrite32(0x2, bar0_120000 + 0x2204);
> > + val = ioread32(bar0_0 + 0x200);
> > + val |= 0x02000000;
> > + iowrite32(val, bar0_0 + 0x200);
> > + val = ioread32(bar0_a00000 + 0x148);
> > + val |= mask;
> > + iowrite32(val, bar0_a00000 + 0x148);
> > +
> > + if ((cmd | cmdmask) != cmd)
> > + pci_write_config_word(pdev, PCI_COMMAND, cmd);
> > + }
> > +
>
>
> It's a little troubling that if something goes wrong with an iomap
> we'll silently fail to re-enable the expected isolation. Seems worthy
> of at least a pci_warn/err. Thanks,
Agreed, but apart from that LGTM.
Regardless of Alex and my disagreement on what the best way to handle
this long term is, this seems like a reasonable interim approach.
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args
From: Steven Rostedt @ 2019-04-04 21:06 UTC (permalink / raw)
To: Dmitry V. Levin
Cc: linux-ia64, Gustavo A. R. Silva, Peter Zijlstra, Palmer Dabbelt,
Dominik Brodowski, Oleg Nesterov, H. Peter Anvin, sparclinux,
linux-riscv, Ingo Molnar, linux-arch, linux-s390, linux-c6x-dev,
linux-sh, linux-hexagon, x86, Ingo Molnar, linux-snps-arc,
Dave Martin, uclinux-h8-devel, linux-xtensa, Kees Cook,
Roland McGrath, linux-um, linux-mips, openrisc, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, linux-arm-kernel, linux-parisc,
linuxppc-dev, linux-kernel, Andy Lutomirski, Eric W. Biederman,
nios2-dev, Andrew Morton, Linus Torvalds
In-Reply-To: <20190404181758.GA8071@altlinux.org>
On Thu, 4 Apr 2019 21:17:58 +0300
"Dmitry V. Levin" <ldv@altlinux.org> wrote:
> There are several places listed below where I'd prefer to see more readable
> equivalents, but feel free to leave it to respective arch maintainers.
I was going to do similar changes, but figured I'd do just that (let
the arch maintainers further optimize the code). I made this more about
fixing the interface and less about the optimization and clean ups that
it can allow.
-- Steve
^ permalink raw reply
* Re: [RFC PATCH kernel v2] powerpc/powernv: Isolate NVLinks between GV100GL on Witherspoon
From: Alex Williamson @ 2019-04-04 20:22 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Jose Ricardo Ziviani, kvm, Sam Bobroff, Daniel Henrique Barboza,
kvm-ppc, Piotr Jaroszynski,
Leonardo Augusto Guimarães Garcia, linuxppc-dev,
David Gibson
In-Reply-To: <20190404052324.90501-1-aik@ozlabs.ru>
On Thu, 4 Apr 2019 16:23:24 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment the POWERNV
> platform puts all interconnected GPUs to the same IOMMU group.
>
> However the user may want to pass individual GPUs to the userspace so
> in order to do so we need to put them into separate IOMMU groups and
> cut off the interconnects.
>
> Thankfully V100 GPUs implement an interface to do by programming link
> disabling mask to BAR0 of a GPU. Once a link is disabled in a GPU using
> this interface, it cannot be re-enabled until the secondary bus reset is
> issued to the GPU.
>
> This adds an extra step to the secondary bus reset handler (the one used
> for such GPUs) to block NVLinks to GPUs which do not belong to the same
> group as the GPU being reset.
>
> This adds a new "isolate_nvlink" kernel parameter to allow GPU isolation;
> when enabled, every GPU gets its own IOMMU group. The new parameter is off
> by default to preserve the existing behaviour.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v2:
> * this is rework of [PATCH kernel RFC 0/2] vfio, powerpc/powernv: Isolate GV100GL
> but this time it is contained in the powernv platform
> ---
> arch/powerpc/platforms/powernv/Makefile | 2 +-
> arch/powerpc/platforms/powernv/pci.h | 1 +
> arch/powerpc/platforms/powernv/eeh-powernv.c | 1 +
> arch/powerpc/platforms/powernv/npu-dma.c | 24 +++-
> arch/powerpc/platforms/powernv/nvlinkgpu.c | 131 +++++++++++++++++++
> 5 files changed, 156 insertions(+), 3 deletions(-)
> create mode 100644 arch/powerpc/platforms/powernv/nvlinkgpu.c
>
> diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
> index da2e99efbd04..60a10d3b36eb 100644
> --- a/arch/powerpc/platforms/powernv/Makefile
> +++ b/arch/powerpc/platforms/powernv/Makefile
> @@ -6,7 +6,7 @@ obj-y += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
> obj-y += opal-kmsg.o opal-powercap.o opal-psr.o opal-sensor-groups.o
>
> obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
> -obj-$(CONFIG_PCI) += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
> +obj-$(CONFIG_PCI) += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o nvlinkgpu.o
> obj-$(CONFIG_CXL_BASE) += pci-cxl.o
> obj-$(CONFIG_EEH) += eeh-powernv.o
> obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
> diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
> index 8e36da379252..9fd3f391482c 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.h
> @@ -250,5 +250,6 @@ extern void pnv_pci_unlink_table_and_group(struct iommu_table *tbl,
> extern void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
> void *tce_mem, u64 tce_size,
> u64 dma_offset, unsigned int page_shift);
> +extern void pnv_try_isolate_nvidia_v100(struct pci_dev *gpdev);
>
> #endif /* __POWERNV_PCI_H */
> diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c b/arch/powerpc/platforms/powernv/eeh-powernv.c
> index f38078976c5d..464b097d9635 100644
> --- a/arch/powerpc/platforms/powernv/eeh-powernv.c
> +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
> @@ -937,6 +937,7 @@ void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
> pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
> pnv_eeh_bridge_reset(dev, EEH_RESET_DEACTIVATE);
> }
> + pnv_try_isolate_nvidia_v100(dev);
> }
>
> static void pnv_eeh_wait_for_pending(struct pci_dn *pdn, const char *type,
> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c b/arch/powerpc/platforms/powernv/npu-dma.c
> index dc23d9d2a7d9..017eae8197e7 100644
> --- a/arch/powerpc/platforms/powernv/npu-dma.c
> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> @@ -529,6 +529,23 @@ static void pnv_comp_attach_table_group(struct npu_comp *npucomp,
> ++npucomp->pe_num;
> }
>
> +static bool isolate_nvlink;
> +
> +static int __init parse_isolate_nvlink(char *p)
> +{
> + bool val;
> +
> + if (!p)
> + val = true;
> + else if (kstrtobool(p, &val))
> + return -EINVAL;
> +
> + isolate_nvlink = val;
> +
> + return 0;
> +}
> +early_param("isolate_nvlink", parse_isolate_nvlink);
> +
> struct iommu_table_group *pnv_try_setup_npu_table_group(struct pnv_ioda_pe *pe)
> {
> struct iommu_table_group *table_group;
> @@ -549,7 +566,7 @@ struct iommu_table_group *pnv_try_setup_npu_table_group(struct pnv_ioda_pe *pe)
>
> hose = pci_bus_to_host(npdev->bus);
>
> - if (hose->npu) {
> + if (hose->npu && !isolate_nvlink) {
> table_group = &hose->npu->npucomp.table_group;
>
> if (!table_group->group) {
> @@ -559,7 +576,10 @@ struct iommu_table_group *pnv_try_setup_npu_table_group(struct pnv_ioda_pe *pe)
> pe->pe_number);
> }
> } else {
> - /* Create a group for 1 GPU and attached NPUs for POWER8 */
> + /*
> + * Create a group for 1 GPU and attached NPUs for
> + * POWER8 (always) or POWER9 (when isolate_nvlink).
> + */
> pe->npucomp = kzalloc(sizeof(*pe->npucomp), GFP_KERNEL);
> table_group = &pe->npucomp->table_group;
> table_group->ops = &pnv_npu_peers_ops;
> diff --git a/arch/powerpc/platforms/powernv/nvlinkgpu.c b/arch/powerpc/platforms/powernv/nvlinkgpu.c
> new file mode 100644
> index 000000000000..dbd8e9d47a05
> --- /dev/null
> +++ b/arch/powerpc/platforms/powernv/nvlinkgpu.c
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * A helper to disable NVLinks between GPUs on IBM Withersponn platform.
> + *
> + * Copyright (C) 2019 IBM Corp. All rights reserved.
> + * Author: Alexey Kardashevskiy <aik@ozlabs.ru>
> + *
> + * 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.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/of.h>
> +#include <linux/iommu.h>
> +#include <linux/pci.h>
> +
> +static int nvlinkgpu_is_ph_in_group(struct device *dev, void *data)
> +{
> + return dev->of_node->phandle == *(phandle *) data;
> +}
> +
> +static u32 nvlinkgpu_get_disable_mask(struct device *dev)
> +{
> + int npu, peer;
> + u32 mask;
> + struct device_node *dn;
> + struct iommu_group *group;
> +
> + dn = dev->of_node;
> + if (!of_find_property(dn, "ibm,nvlink-peers", NULL))
> + return 0;
> +
> + group = iommu_group_get(dev);
> + if (!group)
> + return 0;
> +
> + /*
> + * Collect links to keep which includes links to NPU and links to
> + * other GPUs in the same IOMMU group.
> + */
> + for (npu = 0, mask = 0; ; ++npu) {
> + u32 npuph = 0;
> +
> + if (of_property_read_u32_index(dn, "ibm,npu", npu, &npuph))
> + break;
> +
> + for (peer = 0; ; ++peer) {
> + u32 peerph = 0;
> +
> + if (of_property_read_u32_index(dn, "ibm,nvlink-peers",
> + peer, &peerph))
> + break;
> +
> + if (peerph != npuph &&
> + !iommu_group_for_each_dev(group, &peerph,
> + nvlinkgpu_is_ph_in_group))
> + continue;
> +
> + mask |= 1 << (peer + 16);
> + }
> + }
> + iommu_group_put(group);
> +
> + /* Disabling mechanism takes links to disable so invert it here */
> + mask = ~mask & 0x3F0000;
> +
> + return mask;
> +}
> +
> +void pnv_try_isolate_nvidia_v100(struct pci_dev *bridge)
> +{
> + u32 mask;
> + void __iomem *bar0_0, *bar0_120000, *bar0_a00000;
> + struct pci_dev *pdev;
> +
> + if (!bridge->subordinate)
> + return;
> +
> + pdev = list_first_entry_or_null(&bridge->subordinate->devices,
> + struct pci_dev, bus_list);
> + if (!pdev)
> + return;
> +
> + if (pdev->vendor != PCI_VENDOR_ID_NVIDIA)
> + return;
> +
> + mask = nvlinkgpu_get_disable_mask(&pdev->dev);
> + if (!mask)
> + return;
> +
> + bar0_0 = pci_iomap_range(pdev, 0, 0, 0x10000);
> + bar0_120000 = pci_iomap_range(pdev, 0, 0x120000, 0x10000);
> + bar0_a00000 = pci_iomap_range(pdev, 0, 0xA00000, 0x10000);
> +
> + if (bar0_120000 && bar0_0 && bar0_a00000) {
> + u32 val;
> + u16 cmd = 0, cmdmask = PCI_COMMAND_MEMORY;
> +
> + pci_restore_state(pdev);
> + pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> + if ((cmd & cmdmask) != cmdmask)
> + pci_write_config_word(pdev, PCI_COMMAND, cmd | cmdmask);
> +
> + /*
> + * The sequence is from "Tesla P100 and V100 SXM2 NVLink
> + * Isolation on Multi-Tenant Systems".
> + * The register names are not provided there either,
> + * hence raw values.
> + */
> + iowrite32(0x4, bar0_120000 + 0x4C);
> + iowrite32(0x2, bar0_120000 + 0x2204);
> + val = ioread32(bar0_0 + 0x200);
> + val |= 0x02000000;
> + iowrite32(val, bar0_0 + 0x200);
> + val = ioread32(bar0_a00000 + 0x148);
> + val |= mask;
> + iowrite32(val, bar0_a00000 + 0x148);
> +
> + if ((cmd | cmdmask) != cmd)
> + pci_write_config_word(pdev, PCI_COMMAND, cmd);
> + }
> +
It's a little troubling that if something goes wrong with an iomap
we'll silently fail to re-enable the expected isolation. Seems worthy
of at least a pci_warn/err. Thanks,
Alex
> + if (bar0_0)
> + pci_iounmap(pdev, bar0_0);
> + if (bar0_120000)
> + pci_iounmap(pdev, bar0_120000);
> + if (bar0_a00000)
> + pci_iounmap(pdev, bar0_a00000);
> +}
^ permalink raw reply
* Re: [PATCH RFC 3/5] powerpc/speculation: Add support for 'cpu_spec_mitigations=' cmdline options
From: Timothy Pearson @ 2019-04-04 20:01 UTC (permalink / raw)
To: Jiri Kosina
Cc: Peter Zijlstra, Catalin Marinas, Will Deacon, Paul Mackerras,
H . Peter Anvin, Ingo Molnar, Andrea Arcangeli, linux-s390, x86,
Jon Masters, Waiman Long, linux-arch, Heiko Carstens,
linuxppc-dev, Borislav Petkov, Andy Lutomirski, Josh Poimboeuf,
Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman,
linux-kernel, Tyler Hicks, Martin Schwidefsky, Linus Torvalds
In-Reply-To: <nycvar.YFH.7.76.1904042145590.9803@cbobk.fhfr.pm>
Will be joining in ~ 5 mins. Getting Chromium set up here.
----- Original Message -----
> From: "Jiri Kosina" <jikos@kernel.org>
> To: "Josh Poimboeuf" <jpoimboe@redhat.com>
> Cc: "Peter Zijlstra" <peterz@infradead.org>, "Heiko Carstens" <heiko.carstens@de.ibm.com>, "Paul Mackerras"
> <paulus@samba.org>, "H . Peter Anvin" <hpa@zytor.com>, "Ingo Molnar" <mingo@kernel.org>, "Andrea Arcangeli"
> <aarcange@redhat.com>, linux-s390@vger.kernel.org, x86@kernel.org, "Will Deacon" <will.deacon@arm.com>, "Linus
> Torvalds" <torvalds@linux-foundation.org>, "Catalin Marinas" <catalin.marinas@arm.com>, "Waiman Long"
> <longman@redhat.com>, linux-arch@vger.kernel.org, "Jon Masters" <jcm@redhat.com>, "Borislav Petkov" <bp@alien8.de>,
> "Andy Lutomirski" <luto@kernel.org>, "Thomas Gleixner" <tglx@linutronix.de>, linux-arm-kernel@lists.infradead.org,
> "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, linux-kernel@vger.kernel.org, "Tyler Hicks" <tyhicks@canonical.com>,
> "Martin Schwidefsky" <schwidefsky@de.ibm.com>, linuxppc-dev@lists.ozlabs.org
> Sent: Thursday, April 4, 2019 2:49:05 PM
> Subject: Re: [PATCH RFC 3/5] powerpc/speculation: Add support for 'cpu_spec_mitigations=' cmdline options
> On Thu, 4 Apr 2019, Josh Poimboeuf wrote:
>
>> Configure powerpc CPU runtime speculation bug mitigations in accordance
>> with the 'cpu_spec_mitigations=' cmdline options. This affects
>> Meltdown, Spectre v1, Spectre v2, and Speculative Store Bypass.
> [ ... snip ... ]
>> - if (!no_nospec)
>> + if (!no_nospec && cpu_spec_mitigations != CPU_SPEC_MITIGATIONS_OFF)
>
> '!no_nospec' is something that I am sure will come back to hunt me in my
> bad dreams.
>
> But that's been there already, and fixing it is out of scope of this
> patch. Other than that, as discussed previously -- I really like this new
> global option. Feel free to add
>
> Reviewed-by: Jiri Kosina <jkosina@suse.cz>
>
> for the whole set.
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox