[RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Tomas Winkler]

Intel discrete graphic devices have internal spi storage, that holds
firmware and oprom images. The spi device is exposed to the user space
via mtd framework to be accessed during manufacturing.
The device is hardware locked after manufacturing and only read access
is provided.

The i915 plays role of a multi function device (mfd) and spi device
is exposed as its child device. i915_spi platform driver binds to 
this device.

Because the graphic card may undergo reset at any time and basically hot
unplug all its child devices, this series also provides a fix to the mtd
framework to make the reset graceful.

Tomas Winkler (9):
  drm/i915/spi: add spi device for discrete graphics
  drm/i915/spi: intel_spi_region map
  drm/i915/spi: add driver for on-die spi device
  drm/i915/spi: implement region enumeration
  drm/i915/spi: implement spi access functions
  drm/i915/spi: spi register with mtd
  drm/i915/spi: mtd: implement access handlers
  drm/i915/spi: serialize spi access
  mtd: use refcount to prevent corruption

 drivers/gpu/drm/i915/Kconfig             |   3 +
 drivers/gpu/drm/i915/Makefile            |   6 +
 drivers/gpu/drm/i915/i915_drv.c          |   9 +
 drivers/gpu/drm/i915/i915_drv.h          |   4 +
 drivers/gpu/drm/i915/i915_reg.h          |   1 +
 drivers/gpu/drm/i915/spi/intel_spi.c     |  62 +++
 drivers/gpu/drm/i915/spi/intel_spi.h     |  24 +
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 675 +++++++++++++++++++++++
 drivers/mtd/mtdcore.c                    |  63 ++-
 drivers/mtd/mtdcore.h                    |   1 +
 drivers/mtd/mtdpart.c                    |  13 +-
 include/linux/mtd/mtd.h                  |   2 +-
 12 files changed, 831 insertions(+), 32 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c

-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Tomas Winkler]

Intel discrete graphic devices have internal spi storage, that holds
firmware and oprom images. The spi device is exposed to the user space
via mtd framework to be accessed during manufacturing.
The device is hardware locked after manufacturing and only read access
is provided.

The i915 plays role of a multi function device (mfd) and spi device
is exposed as its child device. i915_spi platform driver binds to 
this device.

Because the graphic card may undergo reset at any time and basically hot
unplug all its child devices, this series also provides a fix to the mtd
framework to make the reset graceful.

Tomas Winkler (9):
  drm/i915/spi: add spi device for discrete graphics
  drm/i915/spi: intel_spi_region map
  drm/i915/spi: add driver for on-die spi device
  drm/i915/spi: implement region enumeration
  drm/i915/spi: implement spi access functions
  drm/i915/spi: spi register with mtd
  drm/i915/spi: mtd: implement access handlers
  drm/i915/spi: serialize spi access
  mtd: use refcount to prevent corruption

 drivers/gpu/drm/i915/Kconfig             |   3 +
 drivers/gpu/drm/i915/Makefile            |   6 +
 drivers/gpu/drm/i915/i915_drv.c          |   9 +
 drivers/gpu/drm/i915/i915_drv.h          |   4 +
 drivers/gpu/drm/i915/i915_reg.h          |   1 +
 drivers/gpu/drm/i915/spi/intel_spi.c     |  62 +++
 drivers/gpu/drm/i915/spi/intel_spi.h     |  24 +
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 675 +++++++++++++++++++++++
 drivers/mtd/mtdcore.c                    |  63 ++-
 drivers/mtd/mtdcore.h                    |   1 +
 drivers/mtd/mtdpart.c                    |  13 +-
 include/linux/mtd/mtd.h                  |   2 +-
 12 files changed, 831 insertions(+), 32 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c

-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFC PATCH 1/9] drm/i915/spi: add spi device for discrete graphics

[Tomas Winkler]

Enable access to internal spi on descrete devices via a child device.
The spi child device is exposed via MFD framework.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com> # v3
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/Kconfig         |  1 +
 drivers/gpu/drm/i915/Makefile        |  3 ++
 drivers/gpu/drm/i915/i915_drv.c      |  9 +++++
 drivers/gpu/drm/i915/i915_drv.h      |  4 +++
 drivers/gpu/drm/i915/i915_reg.h      |  1 +
 drivers/gpu/drm/i915/spi/intel_spi.c | 53 ++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/spi/intel_spi.h | 19 ++++++++++
 7 files changed, 90 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1e1cb245fca7..abcaa8da45ac 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -26,6 +26,7 @@ config DRM_I915
 	select SND_HDA_I915 if SND_HDA_CORE
 	select CEC_CORE if CEC_NOTIFIER
 	select VMAP_PFN
+	select MFD_CORE
 	help
 	  Choose this option if you have a system that has "Intel Graphics
 	  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 235679637d1c..7fa9120feb8d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -191,6 +191,9 @@ i915-y += gt/uc/intel_uc.o \
 	  gt/uc/intel_huc_debugfs.o \
 	  gt/uc/intel_huc_fw.o
 
+# graphics spi device (DGFX) support
+i915-y += spi/intel_spi.o
+
 # modesetting core code
 i915-y += \
 	display/intel_atomic.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3edd5e47ad68..48c383d37212 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -38,6 +38,7 @@
 #include <linux/slab.h>
 #include <linux/vga_switcheroo.h>
 #include <linux/vt.h>
+#include <linux/mfd/core.h>
 
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_ioctl.h>
@@ -67,6 +68,8 @@
 #include "gt/intel_gt_pm.h"
 #include "gt/intel_rc6.h"
 
+#include "spi/intel_spi.h"
+
 #include "i915_debugfs.h"
 #include "i915_drm_client.h"
 #include "i915_drv.h"
@@ -684,6 +687,8 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
 
 	intel_gt_driver_register(&dev_priv->gt);
 
+	intel_spi_init(&dev_priv->spi, dev_priv);
+
 	intel_display_driver_register(dev_priv);
 
 	intel_power_domains_enable(dev_priv);
@@ -710,6 +715,10 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
 
 	intel_display_driver_unregister(dev_priv);
 
+	mfd_remove_devices(&dev_priv->drm.pdev->dev);
+
+	intel_spi_fini(&dev_priv->spi);
+
 	intel_gt_driver_unregister(&dev_priv->gt);
 
 	i915_perf_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f8413b3b9da8..f12ec7606d75 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -85,6 +85,8 @@
 #include "gt/intel_workarounds.h"
 #include "gt/uc/intel_uc.h"
 
+#include "spi/intel_spi.h"
+
 #include "intel_device_info.h"
 #include "intel_pch.h"
 #include "intel_runtime_pm.h"
@@ -1117,6 +1119,8 @@ struct drm_i915_private {
 
 	struct i915_perf perf;
 
+	struct intel_spi spi;
+
 	/* Abstract the submission mechanism (legacy ringbuffer or execlists) away */
 	struct intel_gt gt;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 224ad897af34..426c5dd63673 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2510,6 +2510,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define VEBOX_RING_BASE		0x1a000
 #define GEN11_VEBOX_RING_BASE		0x1c8000
 #define GEN11_VEBOX2_RING_BASE		0x1d8000
+#define GEN12_GUNIT_SPI_BASE	0x00102040
 #define BLT_RING_BASE		0x22000
 #define RING_TAIL(base)		_MMIO((base) + 0x30)
 #define RING_HEAD(base)		_MMIO((base) + 0x34)
diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c b/drivers/gpu/drm/i915/spi/intel_spi.c
new file mode 100644
index 000000000000..07da7197bd5d
--- /dev/null
+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
+ */
+
+#include <linux/mfd/core.h>
+#include <linux/irq.h>
+#include "i915_reg.h"
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "spi/intel_spi.h"
+
+static const struct resource spi_resources[] = {
+	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-spi-mmio"),
+};
+
+static const struct mfd_cell intel_spi_cell = {
+	.id = 2,
+	.name = "i915-spi",
+	.num_resources = ARRAY_SIZE(spi_resources),
+	.resources = spi_resources,
+};
+
+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *dev_priv)
+{
+	struct pci_dev *pdev = dev_priv->drm.pdev;
+	int ret;
+
+	/* Only the DGFX devices have internal SPI */
+	if (!IS_DGFX(dev_priv))
+		return;
+
+	ret = mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
+			      &intel_spi_cell, 1,
+			      &pdev->resource[0], -1, NULL);
+
+	if (ret)
+		dev_err(&pdev->dev, "creating i915-spi cell failed\n");
+
+	spi->i915 = dev_priv;
+}
+
+void intel_spi_fini(struct intel_spi *spi)
+{
+	struct pci_dev *pdev;
+
+	if (!spi->i915)
+		return;
+
+	pdev = spi->i915->drm.pdev;
+
+	dev_dbg(&pdev->dev, "removing i915-spi cell\n");
+}
diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h b/drivers/gpu/drm/i915/spi/intel_spi.h
new file mode 100644
index 000000000000..276551fed993
--- /dev/null
+++ b/drivers/gpu/drm/i915/spi/intel_spi.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_SPI_DEV_H__
+#define __INTEL_SPI_DEV_H__
+
+struct drm_i915_private;
+
+struct intel_spi {
+	struct drm_i915_private *i915;
+};
+
+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *i915);
+
+void intel_spi_fini(struct intel_spi *spi);
+
+#endif /* __INTEL_SPI_DEV_H__ */
-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[Intel-gfx] [RFC PATCH 1/9] drm/i915/spi: add spi device for discrete graphics

[Tomas Winkler]

Enable access to internal spi on descrete devices via a child device.
The spi child device is exposed via MFD framework.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com> # v3
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/Kconfig         |  1 +
 drivers/gpu/drm/i915/Makefile        |  3 ++
 drivers/gpu/drm/i915/i915_drv.c      |  9 +++++
 drivers/gpu/drm/i915/i915_drv.h      |  4 +++
 drivers/gpu/drm/i915/i915_reg.h      |  1 +
 drivers/gpu/drm/i915/spi/intel_spi.c | 53 ++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/spi/intel_spi.h | 19 ++++++++++
 7 files changed, 90 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1e1cb245fca7..abcaa8da45ac 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -26,6 +26,7 @@ config DRM_I915
 	select SND_HDA_I915 if SND_HDA_CORE
 	select CEC_CORE if CEC_NOTIFIER
 	select VMAP_PFN
+	select MFD_CORE
 	help
 	  Choose this option if you have a system that has "Intel Graphics
 	  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 235679637d1c..7fa9120feb8d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -191,6 +191,9 @@ i915-y += gt/uc/intel_uc.o \
 	  gt/uc/intel_huc_debugfs.o \
 	  gt/uc/intel_huc_fw.o
 
+# graphics spi device (DGFX) support
+i915-y += spi/intel_spi.o
+
 # modesetting core code
 i915-y += \
 	display/intel_atomic.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3edd5e47ad68..48c383d37212 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -38,6 +38,7 @@
 #include <linux/slab.h>
 #include <linux/vga_switcheroo.h>
 #include <linux/vt.h>
+#include <linux/mfd/core.h>
 
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_ioctl.h>
@@ -67,6 +68,8 @@
 #include "gt/intel_gt_pm.h"
 #include "gt/intel_rc6.h"
 
+#include "spi/intel_spi.h"
+
 #include "i915_debugfs.h"
 #include "i915_drm_client.h"
 #include "i915_drv.h"
@@ -684,6 +687,8 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
 
 	intel_gt_driver_register(&dev_priv->gt);
 
+	intel_spi_init(&dev_priv->spi, dev_priv);
+
 	intel_display_driver_register(dev_priv);
 
 	intel_power_domains_enable(dev_priv);
@@ -710,6 +715,10 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
 
 	intel_display_driver_unregister(dev_priv);
 
+	mfd_remove_devices(&dev_priv->drm.pdev->dev);
+
+	intel_spi_fini(&dev_priv->spi);
+
 	intel_gt_driver_unregister(&dev_priv->gt);
 
 	i915_perf_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f8413b3b9da8..f12ec7606d75 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -85,6 +85,8 @@
 #include "gt/intel_workarounds.h"
 #include "gt/uc/intel_uc.h"
 
+#include "spi/intel_spi.h"
+
 #include "intel_device_info.h"
 #include "intel_pch.h"
 #include "intel_runtime_pm.h"
@@ -1117,6 +1119,8 @@ struct drm_i915_private {
 
 	struct i915_perf perf;
 
+	struct intel_spi spi;
+
 	/* Abstract the submission mechanism (legacy ringbuffer or execlists) away */
 	struct intel_gt gt;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 224ad897af34..426c5dd63673 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2510,6 +2510,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define VEBOX_RING_BASE		0x1a000
 #define GEN11_VEBOX_RING_BASE		0x1c8000
 #define GEN11_VEBOX2_RING_BASE		0x1d8000
+#define GEN12_GUNIT_SPI_BASE	0x00102040
 #define BLT_RING_BASE		0x22000
 #define RING_TAIL(base)		_MMIO((base) + 0x30)
 #define RING_HEAD(base)		_MMIO((base) + 0x34)
diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c b/drivers/gpu/drm/i915/spi/intel_spi.c
new file mode 100644
index 000000000000..07da7197bd5d
--- /dev/null
+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
+ */
+
+#include <linux/mfd/core.h>
+#include <linux/irq.h>
+#include "i915_reg.h"
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "spi/intel_spi.h"
+
+static const struct resource spi_resources[] = {
+	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-spi-mmio"),
+};
+
+static const struct mfd_cell intel_spi_cell = {
+	.id = 2,
+	.name = "i915-spi",
+	.num_resources = ARRAY_SIZE(spi_resources),
+	.resources = spi_resources,
+};
+
+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *dev_priv)
+{
+	struct pci_dev *pdev = dev_priv->drm.pdev;
+	int ret;
+
+	/* Only the DGFX devices have internal SPI */
+	if (!IS_DGFX(dev_priv))
+		return;
+
+	ret = mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
+			      &intel_spi_cell, 1,
+			      &pdev->resource[0], -1, NULL);
+
+	if (ret)
+		dev_err(&pdev->dev, "creating i915-spi cell failed\n");
+
+	spi->i915 = dev_priv;
+}
+
+void intel_spi_fini(struct intel_spi *spi)
+{
+	struct pci_dev *pdev;
+
+	if (!spi->i915)
+		return;
+
+	pdev = spi->i915->drm.pdev;
+
+	dev_dbg(&pdev->dev, "removing i915-spi cell\n");
+}
diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h b/drivers/gpu/drm/i915/spi/intel_spi.h
new file mode 100644
index 000000000000..276551fed993
--- /dev/null
+++ b/drivers/gpu/drm/i915/spi/intel_spi.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_SPI_DEV_H__
+#define __INTEL_SPI_DEV_H__
+
+struct drm_i915_private;
+
+struct intel_spi {
+	struct drm_i915_private *i915;
+};
+
+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *i915);
+
+void intel_spi_fini(struct intel_spi *spi);
+
+#endif /* __INTEL_SPI_DEV_H__ */
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH 1/9] drm/i915/spi: add spi device for discrete graphics

[Jani Nikula]

On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> Enable access to internal spi on descrete devices via a child device.
> The spi child device is exposed via MFD framework.
>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com> # v3
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> ---
>  drivers/gpu/drm/i915/Kconfig         |  1 +
>  drivers/gpu/drm/i915/Makefile        |  3 ++
>  drivers/gpu/drm/i915/i915_drv.c      |  9 +++++
>  drivers/gpu/drm/i915/i915_drv.h      |  4 +++
>  drivers/gpu/drm/i915/i915_reg.h      |  1 +
>  drivers/gpu/drm/i915/spi/intel_spi.c | 53 ++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/spi/intel_spi.h | 19 ++++++++++
>  7 files changed, 90 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 1e1cb245fca7..abcaa8da45ac 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -26,6 +26,7 @@ config DRM_I915
>  	select SND_HDA_I915 if SND_HDA_CORE
>  	select CEC_CORE if CEC_NOTIFIER
>  	select VMAP_PFN
> +	select MFD_CORE
>  	help
>  	  Choose this option if you have a system that has "Intel Graphics
>  	  Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 235679637d1c..7fa9120feb8d 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -191,6 +191,9 @@ i915-y += gt/uc/intel_uc.o \
>  	  gt/uc/intel_huc_debugfs.o \
>  	  gt/uc/intel_huc_fw.o
>  
> +# graphics spi device (DGFX) support
> +i915-y += spi/intel_spi.o
> +
>  # modesetting core code
>  i915-y += \
>  	display/intel_atomic.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3edd5e47ad68..48c383d37212 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -38,6 +38,7 @@
>  #include <linux/slab.h>
>  #include <linux/vga_switcheroo.h>
>  #include <linux/vt.h>
> +#include <linux/mfd/core.h>
>  
>  #include <drm/drm_atomic_helper.h>
>  #include <drm/drm_ioctl.h>
> @@ -67,6 +68,8 @@
>  #include "gt/intel_gt_pm.h"
>  #include "gt/intel_rc6.h"
>  
> +#include "spi/intel_spi.h"
> +
>  #include "i915_debugfs.h"
>  #include "i915_drm_client.h"
>  #include "i915_drv.h"
> @@ -684,6 +687,8 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
>  
>  	intel_gt_driver_register(&dev_priv->gt);
>  
> +	intel_spi_init(&dev_priv->spi, dev_priv);
> +
>  	intel_display_driver_register(dev_priv);
>  
>  	intel_power_domains_enable(dev_priv);
> @@ -710,6 +715,10 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
>  
>  	intel_display_driver_unregister(dev_priv);
>  
> +	mfd_remove_devices(&dev_priv->drm.pdev->dev);

Please use to_pci_dev(dev_priv->drm.dev).

> +
> +	intel_spi_fini(&dev_priv->spi);
> +
>  	intel_gt_driver_unregister(&dev_priv->gt);
>  
>  	i915_perf_unregister(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f8413b3b9da8..f12ec7606d75 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -85,6 +85,8 @@
>  #include "gt/intel_workarounds.h"
>  #include "gt/uc/intel_uc.h"
>  
> +#include "spi/intel_spi.h"
> +
>  #include "intel_device_info.h"
>  #include "intel_pch.h"
>  #include "intel_runtime_pm.h"
> @@ -1117,6 +1119,8 @@ struct drm_i915_private {
>  
>  	struct i915_perf perf;
>  
> +	struct intel_spi spi;
> +
>  	/* Abstract the submission mechanism (legacy ringbuffer or execlists) away */
>  	struct intel_gt gt;
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 224ad897af34..426c5dd63673 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2510,6 +2510,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define VEBOX_RING_BASE		0x1a000
>  #define GEN11_VEBOX_RING_BASE		0x1c8000
>  #define GEN11_VEBOX2_RING_BASE		0x1d8000
> +#define GEN12_GUNIT_SPI_BASE	0x00102040
>  #define BLT_RING_BASE		0x22000
>  #define RING_TAIL(base)		_MMIO((base) + 0x30)
>  #define RING_HEAD(base)		_MMIO((base) + 0x34)
> diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c b/drivers/gpu/drm/i915/spi/intel_spi.c
> new file mode 100644
> index 000000000000..07da7197bd5d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/spi/intel_spi.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> + */
> +
> +#include <linux/mfd/core.h>
> +#include <linux/irq.h>
> +#include "i915_reg.h"
> +#include "i915_drv.h"
> +#include "gt/intel_gt.h"
> +#include "spi/intel_spi.h"
> +
> +static const struct resource spi_resources[] = {
> +	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-spi-mmio"),
> +};
> +
> +static const struct mfd_cell intel_spi_cell = {
> +	.id = 2,
> +	.name = "i915-spi",
> +	.num_resources = ARRAY_SIZE(spi_resources),
> +	.resources = spi_resources,
> +};
> +
> +void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *dev_priv)
> +{
> +	struct pci_dev *pdev = dev_priv->drm.pdev;

This is going away, please use:

	struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);

While at it, please s/dev_priv/i915/g, that's where we're headed
everywhere. It's just a long process, but let's try to not add new
dev_priv users.

> +	int ret;
> +
> +	/* Only the DGFX devices have internal SPI */
> +	if (!IS_DGFX(dev_priv))
> +		return;
> +
> +	ret = mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
> +			      &intel_spi_cell, 1,
> +			      &pdev->resource[0], -1, NULL);
> +
> +	if (ret)
> +		dev_err(&pdev->dev, "creating i915-spi cell failed\n");
> +
> +	spi->i915 = dev_priv;
> +}
> +
> +void intel_spi_fini(struct intel_spi *spi)
> +{
> +	struct pci_dev *pdev;
> +
> +	if (!spi->i915)
> +		return;
> +
> +	pdev = spi->i915->drm.pdev;

Ditto here, please use to_pci_dev().

> +
> +	dev_dbg(&pdev->dev, "removing i915-spi cell\n");
> +}
> diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h b/drivers/gpu/drm/i915/spi/intel_spi.h
> new file mode 100644
> index 000000000000..276551fed993
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/spi/intel_spi.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> + */
> +
> +#ifndef __INTEL_SPI_DEV_H__
> +#define __INTEL_SPI_DEV_H__

Please make this match the file name.

> +
> +struct drm_i915_private;
> +
> +struct intel_spi {
> +	struct drm_i915_private *i915;
> +};
> +
> +void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *i915);
> +
> +void intel_spi_fini(struct intel_spi *spi);
> +
> +#endif /* __INTEL_SPI_DEV_H__ */

-- 
Jani Nikula, Intel Open Source Graphics Center

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 1/9] drm/i915/spi: add spi device for discrete graphics

[Jani Nikula]

On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> Enable access to internal spi on descrete devices via a child device.
> The spi child device is exposed via MFD framework.
>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com> # v3
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> ---
>  drivers/gpu/drm/i915/Kconfig         |  1 +
>  drivers/gpu/drm/i915/Makefile        |  3 ++
>  drivers/gpu/drm/i915/i915_drv.c      |  9 +++++
>  drivers/gpu/drm/i915/i915_drv.h      |  4 +++
>  drivers/gpu/drm/i915/i915_reg.h      |  1 +
>  drivers/gpu/drm/i915/spi/intel_spi.c | 53 ++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/spi/intel_spi.h | 19 ++++++++++
>  7 files changed, 90 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 1e1cb245fca7..abcaa8da45ac 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -26,6 +26,7 @@ config DRM_I915
>  	select SND_HDA_I915 if SND_HDA_CORE
>  	select CEC_CORE if CEC_NOTIFIER
>  	select VMAP_PFN
> +	select MFD_CORE
>  	help
>  	  Choose this option if you have a system that has "Intel Graphics
>  	  Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 235679637d1c..7fa9120feb8d 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -191,6 +191,9 @@ i915-y += gt/uc/intel_uc.o \
>  	  gt/uc/intel_huc_debugfs.o \
>  	  gt/uc/intel_huc_fw.o
>  
> +# graphics spi device (DGFX) support
> +i915-y += spi/intel_spi.o
> +
>  # modesetting core code
>  i915-y += \
>  	display/intel_atomic.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3edd5e47ad68..48c383d37212 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -38,6 +38,7 @@
>  #include <linux/slab.h>
>  #include <linux/vga_switcheroo.h>
>  #include <linux/vt.h>
> +#include <linux/mfd/core.h>
>  
>  #include <drm/drm_atomic_helper.h>
>  #include <drm/drm_ioctl.h>
> @@ -67,6 +68,8 @@
>  #include "gt/intel_gt_pm.h"
>  #include "gt/intel_rc6.h"
>  
> +#include "spi/intel_spi.h"
> +
>  #include "i915_debugfs.h"
>  #include "i915_drm_client.h"
>  #include "i915_drv.h"
> @@ -684,6 +687,8 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
>  
>  	intel_gt_driver_register(&dev_priv->gt);
>  
> +	intel_spi_init(&dev_priv->spi, dev_priv);
> +
>  	intel_display_driver_register(dev_priv);
>  
>  	intel_power_domains_enable(dev_priv);
> @@ -710,6 +715,10 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
>  
>  	intel_display_driver_unregister(dev_priv);
>  
> +	mfd_remove_devices(&dev_priv->drm.pdev->dev);

Please use to_pci_dev(dev_priv->drm.dev).

> +
> +	intel_spi_fini(&dev_priv->spi);
> +
>  	intel_gt_driver_unregister(&dev_priv->gt);
>  
>  	i915_perf_unregister(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f8413b3b9da8..f12ec7606d75 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -85,6 +85,8 @@
>  #include "gt/intel_workarounds.h"
>  #include "gt/uc/intel_uc.h"
>  
> +#include "spi/intel_spi.h"
> +
>  #include "intel_device_info.h"
>  #include "intel_pch.h"
>  #include "intel_runtime_pm.h"
> @@ -1117,6 +1119,8 @@ struct drm_i915_private {
>  
>  	struct i915_perf perf;
>  
> +	struct intel_spi spi;
> +
>  	/* Abstract the submission mechanism (legacy ringbuffer or execlists) away */
>  	struct intel_gt gt;
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 224ad897af34..426c5dd63673 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2510,6 +2510,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define VEBOX_RING_BASE		0x1a000
>  #define GEN11_VEBOX_RING_BASE		0x1c8000
>  #define GEN11_VEBOX2_RING_BASE		0x1d8000
> +#define GEN12_GUNIT_SPI_BASE	0x00102040
>  #define BLT_RING_BASE		0x22000
>  #define RING_TAIL(base)		_MMIO((base) + 0x30)
>  #define RING_HEAD(base)		_MMIO((base) + 0x34)
> diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c b/drivers/gpu/drm/i915/spi/intel_spi.c
> new file mode 100644
> index 000000000000..07da7197bd5d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/spi/intel_spi.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> + */
> +
> +#include <linux/mfd/core.h>
> +#include <linux/irq.h>
> +#include "i915_reg.h"
> +#include "i915_drv.h"
> +#include "gt/intel_gt.h"
> +#include "spi/intel_spi.h"
> +
> +static const struct resource spi_resources[] = {
> +	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-spi-mmio"),
> +};
> +
> +static const struct mfd_cell intel_spi_cell = {
> +	.id = 2,
> +	.name = "i915-spi",
> +	.num_resources = ARRAY_SIZE(spi_resources),
> +	.resources = spi_resources,
> +};
> +
> +void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *dev_priv)
> +{
> +	struct pci_dev *pdev = dev_priv->drm.pdev;

This is going away, please use:

	struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);

While at it, please s/dev_priv/i915/g, that's where we're headed
everywhere. It's just a long process, but let's try to not add new
dev_priv users.

> +	int ret;
> +
> +	/* Only the DGFX devices have internal SPI */
> +	if (!IS_DGFX(dev_priv))
> +		return;
> +
> +	ret = mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
> +			      &intel_spi_cell, 1,
> +			      &pdev->resource[0], -1, NULL);
> +
> +	if (ret)
> +		dev_err(&pdev->dev, "creating i915-spi cell failed\n");
> +
> +	spi->i915 = dev_priv;
> +}
> +
> +void intel_spi_fini(struct intel_spi *spi)
> +{
> +	struct pci_dev *pdev;
> +
> +	if (!spi->i915)
> +		return;
> +
> +	pdev = spi->i915->drm.pdev;

Ditto here, please use to_pci_dev().

> +
> +	dev_dbg(&pdev->dev, "removing i915-spi cell\n");
> +}
> diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h b/drivers/gpu/drm/i915/spi/intel_spi.h
> new file mode 100644
> index 000000000000..276551fed993
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/spi/intel_spi.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> + */
> +
> +#ifndef __INTEL_SPI_DEV_H__
> +#define __INTEL_SPI_DEV_H__

Please make this match the file name.

> +
> +struct drm_i915_private;
> +
> +struct intel_spi {
> +	struct drm_i915_private *i915;
> +};
> +
> +void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *i915);
> +
> +void intel_spi_fini(struct intel_spi *spi);
> +
> +#endif /* __INTEL_SPI_DEV_H__ */

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH 1/9] drm/i915/spi: add spi device for discrete graphics

[Lucas De Marchi]

On Tue, Feb 16, 2021 at 08:19:17PM +0200, Tomas Winkler wrote:
>Enable access to internal spi on descrete devices via a child device.
>The spi child device is exposed via MFD framework.
>
>Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>Cc: Lucas De Marchi <lucas.demarchi@intel.com> # v3
>Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>---
> drivers/gpu/drm/i915/Kconfig         |  1 +
> drivers/gpu/drm/i915/Makefile        |  3 ++
> drivers/gpu/drm/i915/i915_drv.c      |  9 +++++
> drivers/gpu/drm/i915/i915_drv.h      |  4 +++
> drivers/gpu/drm/i915/i915_reg.h      |  1 +
> drivers/gpu/drm/i915/spi/intel_spi.c | 53 ++++++++++++++++++++++++++++
> drivers/gpu/drm/i915/spi/intel_spi.h | 19 ++++++++++
> 7 files changed, 90 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
> create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
>
>diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>index 1e1cb245fca7..abcaa8da45ac 100644
>--- a/drivers/gpu/drm/i915/Kconfig
>+++ b/drivers/gpu/drm/i915/Kconfig
>@@ -26,6 +26,7 @@ config DRM_I915
> 	select SND_HDA_I915 if SND_HDA_CORE
> 	select CEC_CORE if CEC_NOTIFIER
> 	select VMAP_PFN
>+	select MFD_CORE
> 	help
> 	  Choose this option if you have a system that has "Intel Graphics
> 	  Media Accelerator" or "HD Graphics" integrated graphics,
>diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>index 235679637d1c..7fa9120feb8d 100644
>--- a/drivers/gpu/drm/i915/Makefile
>+++ b/drivers/gpu/drm/i915/Makefile
>@@ -191,6 +191,9 @@ i915-y += gt/uc/intel_uc.o \
> 	  gt/uc/intel_huc_debugfs.o \
> 	  gt/uc/intel_huc_fw.o
>
>+# graphics spi device (DGFX) support
>+i915-y += spi/intel_spi.o
>+
> # modesetting core code
> i915-y += \
> 	display/intel_atomic.o \
>diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
>index 3edd5e47ad68..48c383d37212 100644
>--- a/drivers/gpu/drm/i915/i915_drv.c
>+++ b/drivers/gpu/drm/i915/i915_drv.c
>@@ -38,6 +38,7 @@
> #include <linux/slab.h>
> #include <linux/vga_switcheroo.h>
> #include <linux/vt.h>
>+#include <linux/mfd/core.h>
>
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_ioctl.h>
>@@ -67,6 +68,8 @@
> #include "gt/intel_gt_pm.h"
> #include "gt/intel_rc6.h"
>
>+#include "spi/intel_spi.h"
>+
> #include "i915_debugfs.h"
> #include "i915_drm_client.h"
> #include "i915_drv.h"
>@@ -684,6 +687,8 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
>
> 	intel_gt_driver_register(&dev_priv->gt);
>
>+	intel_spi_init(&dev_priv->spi, dev_priv);
>+
> 	intel_display_driver_register(dev_priv);


any reason why this is between gt and display init?  I think it would be
better to call this before gt_driver_register. It doesn't need gt and if
eventually display also needs to register mfd devices, the unregister
counter part of this wouldn't be so ackward.

Naming-wise, most of the functions called here are "*_register()".
Shouldn't we follow suit and name it intel_spi_driver_register()?

>
> 	intel_power_domains_enable(dev_priv);
>@@ -710,6 +715,10 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
>
> 	intel_display_driver_unregister(dev_priv);
>
>+	mfd_remove_devices(&dev_priv->drm.pdev->dev);
>+
>+	intel_spi_fini(&dev_priv->spi);

see below, I don't think we actually need/want this. I'd rather have a
comment here explaining why we are not "unpeeling the onion" wrt to the
register function:

	/*
	 * mfd drivers are added separately, but removed all at once
	 * from dev_priv
	 */
	mfd_remove_devices(&dev_priv->drm.pdev->dev);

>+
> 	intel_gt_driver_unregister(&dev_priv->gt);
>
> 	i915_perf_unregister(dev_priv);
>diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>index f8413b3b9da8..f12ec7606d75 100644
>--- a/drivers/gpu/drm/i915/i915_drv.h
>+++ b/drivers/gpu/drm/i915/i915_drv.h
>@@ -85,6 +85,8 @@
> #include "gt/intel_workarounds.h"
> #include "gt/uc/intel_uc.h"
>
>+#include "spi/intel_spi.h"
>+
> #include "intel_device_info.h"
> #include "intel_pch.h"
> #include "intel_runtime_pm.h"
>@@ -1117,6 +1119,8 @@ struct drm_i915_private {
>
> 	struct i915_perf perf;
>
>+	struct intel_spi spi;
>+
> 	/* Abstract the submission mechanism (legacy ringbuffer or execlists) away */
> 	struct intel_gt gt;
>
>diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>index 224ad897af34..426c5dd63673 100644
>--- a/drivers/gpu/drm/i915/i915_reg.h
>+++ b/drivers/gpu/drm/i915/i915_reg.h
>@@ -2510,6 +2510,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define VEBOX_RING_BASE		0x1a000
> #define GEN11_VEBOX_RING_BASE		0x1c8000
> #define GEN11_VEBOX2_RING_BASE		0x1d8000
>+#define GEN12_GUNIT_SPI_BASE	0x00102040
> #define BLT_RING_BASE		0x22000
> #define RING_TAIL(base)		_MMIO((base) + 0x30)
> #define RING_HEAD(base)		_MMIO((base) + 0x34)
>diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c b/drivers/gpu/drm/i915/spi/intel_spi.c
>new file mode 100644
>index 000000000000..07da7197bd5d
>--- /dev/null
>+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
>@@ -0,0 +1,53 @@
>+// SPDX-License-Identifier: MIT
>+/*
>+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
>+ */
>+
>+#include <linux/mfd/core.h>
>+#include <linux/irq.h>
>+#include "i915_reg.h"
>+#include "i915_drv.h"
>+#include "gt/intel_gt.h"
>+#include "spi/intel_spi.h"
>+
>+static const struct resource spi_resources[] = {
>+	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-spi-mmio"),
>+};
>+
>+static const struct mfd_cell intel_spi_cell = {
>+	.id = 2,
>+	.name = "i915-spi",
>+	.num_resources = ARRAY_SIZE(spi_resources),
>+	.resources = spi_resources,
>+};
>+
>+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *dev_priv)
>+{
>+	struct pci_dev *pdev = dev_priv->drm.pdev;
>+	int ret;
>+
>+	/* Only the DGFX devices have internal SPI */
>+	if (!IS_DGFX(dev_priv))
>+		return;
>+
>+	ret = mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
>+			      &intel_spi_cell, 1,
>+			      &pdev->resource[0], -1, NULL);
>+
>+	if (ret)
>+		dev_err(&pdev->dev, "creating i915-spi cell failed\n");
>+
>+	spi->i915 = dev_priv;
>+}
>+
>+void intel_spi_fini(struct intel_spi *spi)
>+{
>+	struct pci_dev *pdev;
>+
>+	if (!spi->i915)
>+		return;
>+
>+	pdev = spi->i915->drm.pdev;
>+
>+	dev_dbg(&pdev->dev, "removing i915-spi cell\n");

this is actually a NOP. I don't think we actually need it since mfd
devices are removed all at once from the driver

>+}
>diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h b/drivers/gpu/drm/i915/spi/intel_spi.h
>new file mode 100644
>index 000000000000..276551fed993
>--- /dev/null
>+++ b/drivers/gpu/drm/i915/spi/intel_spi.h
>@@ -0,0 +1,19 @@
>+/* SPDX-License-Identifier: MIT */
>+/*
>+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
>+ */
>+
>+#ifndef __INTEL_SPI_DEV_H__
>+#define __INTEL_SPI_DEV_H__
>+
>+struct drm_i915_private;
>+
>+struct intel_spi {
>+	struct drm_i915_private *i915;
>+};
>+
>+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *i915);
>+
>+void intel_spi_fini(struct intel_spi *spi);
>+
>+#endif /* __INTEL_SPI_DEV_H__ */
>-- 
>2.26.2
>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 1/9] drm/i915/spi: add spi device for discrete graphics

[Lucas De Marchi]

On Tue, Feb 16, 2021 at 08:19:17PM +0200, Tomas Winkler wrote:
>Enable access to internal spi on descrete devices via a child device.
>The spi child device is exposed via MFD framework.
>
>Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>Cc: Lucas De Marchi <lucas.demarchi@intel.com> # v3
>Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>---
> drivers/gpu/drm/i915/Kconfig         |  1 +
> drivers/gpu/drm/i915/Makefile        |  3 ++
> drivers/gpu/drm/i915/i915_drv.c      |  9 +++++
> drivers/gpu/drm/i915/i915_drv.h      |  4 +++
> drivers/gpu/drm/i915/i915_reg.h      |  1 +
> drivers/gpu/drm/i915/spi/intel_spi.c | 53 ++++++++++++++++++++++++++++
> drivers/gpu/drm/i915/spi/intel_spi.h | 19 ++++++++++
> 7 files changed, 90 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
> create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
>
>diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>index 1e1cb245fca7..abcaa8da45ac 100644
>--- a/drivers/gpu/drm/i915/Kconfig
>+++ b/drivers/gpu/drm/i915/Kconfig
>@@ -26,6 +26,7 @@ config DRM_I915
> 	select SND_HDA_I915 if SND_HDA_CORE
> 	select CEC_CORE if CEC_NOTIFIER
> 	select VMAP_PFN
>+	select MFD_CORE
> 	help
> 	  Choose this option if you have a system that has "Intel Graphics
> 	  Media Accelerator" or "HD Graphics" integrated graphics,
>diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>index 235679637d1c..7fa9120feb8d 100644
>--- a/drivers/gpu/drm/i915/Makefile
>+++ b/drivers/gpu/drm/i915/Makefile
>@@ -191,6 +191,9 @@ i915-y += gt/uc/intel_uc.o \
> 	  gt/uc/intel_huc_debugfs.o \
> 	  gt/uc/intel_huc_fw.o
>
>+# graphics spi device (DGFX) support
>+i915-y += spi/intel_spi.o
>+
> # modesetting core code
> i915-y += \
> 	display/intel_atomic.o \
>diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
>index 3edd5e47ad68..48c383d37212 100644
>--- a/drivers/gpu/drm/i915/i915_drv.c
>+++ b/drivers/gpu/drm/i915/i915_drv.c
>@@ -38,6 +38,7 @@
> #include <linux/slab.h>
> #include <linux/vga_switcheroo.h>
> #include <linux/vt.h>
>+#include <linux/mfd/core.h>
>
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_ioctl.h>
>@@ -67,6 +68,8 @@
> #include "gt/intel_gt_pm.h"
> #include "gt/intel_rc6.h"
>
>+#include "spi/intel_spi.h"
>+
> #include "i915_debugfs.h"
> #include "i915_drm_client.h"
> #include "i915_drv.h"
>@@ -684,6 +687,8 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
>
> 	intel_gt_driver_register(&dev_priv->gt);
>
>+	intel_spi_init(&dev_priv->spi, dev_priv);
>+
> 	intel_display_driver_register(dev_priv);


any reason why this is between gt and display init?  I think it would be
better to call this before gt_driver_register. It doesn't need gt and if
eventually display also needs to register mfd devices, the unregister
counter part of this wouldn't be so ackward.

Naming-wise, most of the functions called here are "*_register()".
Shouldn't we follow suit and name it intel_spi_driver_register()?

>
> 	intel_power_domains_enable(dev_priv);
>@@ -710,6 +715,10 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
>
> 	intel_display_driver_unregister(dev_priv);
>
>+	mfd_remove_devices(&dev_priv->drm.pdev->dev);
>+
>+	intel_spi_fini(&dev_priv->spi);

see below, I don't think we actually need/want this. I'd rather have a
comment here explaining why we are not "unpeeling the onion" wrt to the
register function:

	/*
	 * mfd drivers are added separately, but removed all at once
	 * from dev_priv
	 */
	mfd_remove_devices(&dev_priv->drm.pdev->dev);

>+
> 	intel_gt_driver_unregister(&dev_priv->gt);
>
> 	i915_perf_unregister(dev_priv);
>diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>index f8413b3b9da8..f12ec7606d75 100644
>--- a/drivers/gpu/drm/i915/i915_drv.h
>+++ b/drivers/gpu/drm/i915/i915_drv.h
>@@ -85,6 +85,8 @@
> #include "gt/intel_workarounds.h"
> #include "gt/uc/intel_uc.h"
>
>+#include "spi/intel_spi.h"
>+
> #include "intel_device_info.h"
> #include "intel_pch.h"
> #include "intel_runtime_pm.h"
>@@ -1117,6 +1119,8 @@ struct drm_i915_private {
>
> 	struct i915_perf perf;
>
>+	struct intel_spi spi;
>+
> 	/* Abstract the submission mechanism (legacy ringbuffer or execlists) away */
> 	struct intel_gt gt;
>
>diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>index 224ad897af34..426c5dd63673 100644
>--- a/drivers/gpu/drm/i915/i915_reg.h
>+++ b/drivers/gpu/drm/i915/i915_reg.h
>@@ -2510,6 +2510,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define VEBOX_RING_BASE		0x1a000
> #define GEN11_VEBOX_RING_BASE		0x1c8000
> #define GEN11_VEBOX2_RING_BASE		0x1d8000
>+#define GEN12_GUNIT_SPI_BASE	0x00102040
> #define BLT_RING_BASE		0x22000
> #define RING_TAIL(base)		_MMIO((base) + 0x30)
> #define RING_HEAD(base)		_MMIO((base) + 0x34)
>diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c b/drivers/gpu/drm/i915/spi/intel_spi.c
>new file mode 100644
>index 000000000000..07da7197bd5d
>--- /dev/null
>+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
>@@ -0,0 +1,53 @@
>+// SPDX-License-Identifier: MIT
>+/*
>+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
>+ */
>+
>+#include <linux/mfd/core.h>
>+#include <linux/irq.h>
>+#include "i915_reg.h"
>+#include "i915_drv.h"
>+#include "gt/intel_gt.h"
>+#include "spi/intel_spi.h"
>+
>+static const struct resource spi_resources[] = {
>+	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-spi-mmio"),
>+};
>+
>+static const struct mfd_cell intel_spi_cell = {
>+	.id = 2,
>+	.name = "i915-spi",
>+	.num_resources = ARRAY_SIZE(spi_resources),
>+	.resources = spi_resources,
>+};
>+
>+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *dev_priv)
>+{
>+	struct pci_dev *pdev = dev_priv->drm.pdev;
>+	int ret;
>+
>+	/* Only the DGFX devices have internal SPI */
>+	if (!IS_DGFX(dev_priv))
>+		return;
>+
>+	ret = mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
>+			      &intel_spi_cell, 1,
>+			      &pdev->resource[0], -1, NULL);
>+
>+	if (ret)
>+		dev_err(&pdev->dev, "creating i915-spi cell failed\n");
>+
>+	spi->i915 = dev_priv;
>+}
>+
>+void intel_spi_fini(struct intel_spi *spi)
>+{
>+	struct pci_dev *pdev;
>+
>+	if (!spi->i915)
>+		return;
>+
>+	pdev = spi->i915->drm.pdev;
>+
>+	dev_dbg(&pdev->dev, "removing i915-spi cell\n");

this is actually a NOP. I don't think we actually need it since mfd
devices are removed all at once from the driver

>+}
>diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h b/drivers/gpu/drm/i915/spi/intel_spi.h
>new file mode 100644
>index 000000000000..276551fed993
>--- /dev/null
>+++ b/drivers/gpu/drm/i915/spi/intel_spi.h
>@@ -0,0 +1,19 @@
>+/* SPDX-License-Identifier: MIT */
>+/*
>+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
>+ */
>+
>+#ifndef __INTEL_SPI_DEV_H__
>+#define __INTEL_SPI_DEV_H__
>+
>+struct drm_i915_private;
>+
>+struct intel_spi {
>+	struct drm_i915_private *i915;
>+};
>+
>+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *i915);
>+
>+void intel_spi_fini(struct intel_spi *spi);
>+
>+#endif /* __INTEL_SPI_DEV_H__ */
>-- 
>2.26.2
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 1/9] drm/i915/spi: add spi device for discrete graphics

[Winkler, Tomas]

> On Tue, Feb 16, 2021 at 08:19:17PM +0200, Tomas Winkler wrote:
> >Enable access to internal spi on descrete devices via a child device.
> >The spi child device is exposed via MFD framework.
> >
> >Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >Cc: Lucas De Marchi <lucas.demarchi@intel.com> # v3
> >Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> >---
> > drivers/gpu/drm/i915/Kconfig         |  1 +
> > drivers/gpu/drm/i915/Makefile        |  3 ++
> > drivers/gpu/drm/i915/i915_drv.c      |  9 +++++
> > drivers/gpu/drm/i915/i915_drv.h      |  4 +++
> > drivers/gpu/drm/i915/i915_reg.h      |  1 +
> > drivers/gpu/drm/i915/spi/intel_spi.c | 53
> ++++++++++++++++++++++++++++
> >drivers/gpu/drm/i915/spi/intel_spi.h | 19 ++++++++++
> > 7 files changed, 90 insertions(+)
> > create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
> > create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
> >
> >diff --git a/drivers/gpu/drm/i915/Kconfig
> >b/drivers/gpu/drm/i915/Kconfig index 1e1cb245fca7..abcaa8da45ac 100644
> >--- a/drivers/gpu/drm/i915/Kconfig
> >+++ b/drivers/gpu/drm/i915/Kconfig
> >@@ -26,6 +26,7 @@ config DRM_I915
> > 	select SND_HDA_I915 if SND_HDA_CORE
> > 	select CEC_CORE if CEC_NOTIFIER
> > 	select VMAP_PFN
> >+	select MFD_CORE
> > 	help
> > 	  Choose this option if you have a system that has "Intel Graphics
> > 	  Media Accelerator" or "HD Graphics" integrated graphics, diff --git
> >a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index
> >235679637d1c..7fa9120feb8d 100644
> >--- a/drivers/gpu/drm/i915/Makefile
> >+++ b/drivers/gpu/drm/i915/Makefile
> >@@ -191,6 +191,9 @@ i915-y += gt/uc/intel_uc.o \
> > 	  gt/uc/intel_huc_debugfs.o \
> > 	  gt/uc/intel_huc_fw.o
> >
> >+# graphics spi device (DGFX) support
> >+i915-y += spi/intel_spi.o
> >+
> > # modesetting core code
> > i915-y += \
> > 	display/intel_atomic.o \
> >diff --git a/drivers/gpu/drm/i915/i915_drv.c
> >b/drivers/gpu/drm/i915/i915_drv.c index 3edd5e47ad68..48c383d37212
> >100644
> >--- a/drivers/gpu/drm/i915/i915_drv.c
> >+++ b/drivers/gpu/drm/i915/i915_drv.c
> >@@ -38,6 +38,7 @@
> > #include <linux/slab.h>
> > #include <linux/vga_switcheroo.h>
> > #include <linux/vt.h>
> >+#include <linux/mfd/core.h>
> >
> > #include <drm/drm_atomic_helper.h>
> > #include <drm/drm_ioctl.h>
> >@@ -67,6 +68,8 @@
> > #include "gt/intel_gt_pm.h"
> > #include "gt/intel_rc6.h"
> >
> >+#include "spi/intel_spi.h"
> >+
> > #include "i915_debugfs.h"
> > #include "i915_drm_client.h"
> > #include "i915_drv.h"
> >@@ -684,6 +687,8 @@ static void i915_driver_register(struct
> >drm_i915_private *dev_priv)
> >
> > 	intel_gt_driver_register(&dev_priv->gt);
> >
> >+	intel_spi_init(&dev_priv->spi, dev_priv);
> >+
> > 	intel_display_driver_register(dev_priv);
> 
> 
> any reason why this is between gt and display init?  I think it would be better
> to call this before gt_driver_register. It doesn't need gt and if eventually
> display also needs to register mfd devices, the unregister counter part of this
> wouldn't be so ackward.

It doesn't really matter, actually gt driver will register additional mfd devices I'm not aware of display mfd devices.

> 
> Naming-wise, most of the functions called here are "*_register()".
> Shouldn't we follow suit and name it intel_spi_driver_register()?

It's not a driver we are initializing but a  device here. If I remember correctly the name was suggested in internal review. 

> 
> >
> > 	intel_power_domains_enable(dev_priv);
> >@@ -710,6 +715,10 @@ static void i915_driver_unregister(struct
> >drm_i915_private *dev_priv)
> >
> > 	intel_display_driver_unregister(dev_priv);
> >
> >+	mfd_remove_devices(&dev_priv->drm.pdev->dev);
> >+
> >+	intel_spi_fini(&dev_priv->spi);
> 
> see below, I don't think we actually need/want this. I'd rather have a
> comment here explaining why we are not "unpeeling the onion" wrt to the
> register function:

The is a result of bad rebase, good catch, the above code is correct. 
> 
> 	/*
> 	 * mfd drivers are added separately, but removed all at once
> 	 * from dev_priv
> 	 */
> 	mfd_remove_devices(&dev_priv->drm.pdev->dev);
> 
> >+
> > 	intel_gt_driver_unregister(&dev_priv->gt);
> >
> > 	i915_perf_unregister(dev_priv);
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >b/drivers/gpu/drm/i915/i915_drv.h index f8413b3b9da8..f12ec7606d75
> >100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -85,6 +85,8 @@
> > #include "gt/intel_workarounds.h"
> > #include "gt/uc/intel_uc.h"
> >
> >+#include "spi/intel_spi.h"
> >+
> > #include "intel_device_info.h"
> > #include "intel_pch.h"
> > #include "intel_runtime_pm.h"
> >@@ -1117,6 +1119,8 @@ struct drm_i915_private {
> >
> > 	struct i915_perf perf;
> >
> >+	struct intel_spi spi;
> >+
> > 	/* Abstract the submission mechanism (legacy ringbuffer or
> execlists) away */
> > 	struct intel_gt gt;
> >
> >diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >b/drivers/gpu/drm/i915/i915_reg.h index 224ad897af34..426c5dd63673
> >100644
> >--- a/drivers/gpu/drm/i915/i915_reg.h
> >+++ b/drivers/gpu/drm/i915/i915_reg.h
> >@@ -2510,6 +2510,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t
> reg)
> > #define VEBOX_RING_BASE		0x1a000
> > #define GEN11_VEBOX_RING_BASE		0x1c8000
> > #define GEN11_VEBOX2_RING_BASE		0x1d8000
> >+#define GEN12_GUNIT_SPI_BASE	0x00102040
> > #define BLT_RING_BASE		0x22000
> > #define RING_TAIL(base)		_MMIO((base) + 0x30)
> > #define RING_HEAD(base)		_MMIO((base) + 0x34)
> >diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
> >b/drivers/gpu/drm/i915/spi/intel_spi.c
> >new file mode 100644
> >index 000000000000..07da7197bd5d
> >--- /dev/null
> >+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
> >@@ -0,0 +1,53 @@
> >+// SPDX-License-Identifier: MIT
> >+/*
> >+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> >+ */
> >+
> >+#include <linux/mfd/core.h>
> >+#include <linux/irq.h>
> >+#include "i915_reg.h"
> >+#include "i915_drv.h"
> >+#include "gt/intel_gt.h"
> >+#include "spi/intel_spi.h"
> >+
> >+static const struct resource spi_resources[] = {
> >+	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-
> spi-mmio"), };
> >+
> >+static const struct mfd_cell intel_spi_cell = {
> >+	.id = 2,
> >+	.name = "i915-spi",
> >+	.num_resources = ARRAY_SIZE(spi_resources),
> >+	.resources = spi_resources,
> >+};
> >+
> >+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private
> >+*dev_priv) {
> >+	struct pci_dev *pdev = dev_priv->drm.pdev;
> >+	int ret;
> >+
> >+	/* Only the DGFX devices have internal SPI */
> >+	if (!IS_DGFX(dev_priv))
> >+		return;
> >+
> >+	ret = mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
> >+			      &intel_spi_cell, 1,
> >+			      &pdev->resource[0], -1, NULL);
> >+
> >+	if (ret)
> >+		dev_err(&pdev->dev, "creating i915-spi cell failed\n");
> >+
> >+	spi->i915 = dev_priv;
> >+}
> >+
> >+void intel_spi_fini(struct intel_spi *spi) {
> >+	struct pci_dev *pdev;
> >+
> >+	if (!spi->i915)
> >+		return;
> >+
> >+	pdev = spi->i915->drm.pdev;
> >+
> >+	dev_dbg(&pdev->dev, "removing i915-spi cell\n");
> 
> this is actually a NOP. I don't think we actually need it since mfd devices are
> removed all at once from the driver

There was intention to use that code, but it's a leftover I will drop it. 

> 
> >+}
> >diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h
> >b/drivers/gpu/drm/i915/spi/intel_spi.h
> >new file mode 100644
> >index 000000000000..276551fed993
> >--- /dev/null
> >+++ b/drivers/gpu/drm/i915/spi/intel_spi.h
> >@@ -0,0 +1,19 @@
> >+/* SPDX-License-Identifier: MIT */
> >+/*
> >+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> >+ */
> >+
> >+#ifndef __INTEL_SPI_DEV_H__
> >+#define __INTEL_SPI_DEV_H__
> >+
> >+struct drm_i915_private;
> >+
> >+struct intel_spi {
> >+	struct drm_i915_private *i915;
> >+};
> >+
> >+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private
> >+*i915);
> >+
> >+void intel_spi_fini(struct intel_spi *spi);
> >+
> >+#endif /* __INTEL_SPI_DEV_H__ */
> >--
> >2.26.2
> >

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 1/9] drm/i915/spi: add spi device for discrete graphics

[Winkler, Tomas]

> On Tue, Feb 16, 2021 at 08:19:17PM +0200, Tomas Winkler wrote:
> >Enable access to internal spi on descrete devices via a child device.
> >The spi child device is exposed via MFD framework.
> >
> >Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >Cc: Lucas De Marchi <lucas.demarchi@intel.com> # v3
> >Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> >---
> > drivers/gpu/drm/i915/Kconfig         |  1 +
> > drivers/gpu/drm/i915/Makefile        |  3 ++
> > drivers/gpu/drm/i915/i915_drv.c      |  9 +++++
> > drivers/gpu/drm/i915/i915_drv.h      |  4 +++
> > drivers/gpu/drm/i915/i915_reg.h      |  1 +
> > drivers/gpu/drm/i915/spi/intel_spi.c | 53
> ++++++++++++++++++++++++++++
> >drivers/gpu/drm/i915/spi/intel_spi.h | 19 ++++++++++
> > 7 files changed, 90 insertions(+)
> > create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
> > create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
> >
> >diff --git a/drivers/gpu/drm/i915/Kconfig
> >b/drivers/gpu/drm/i915/Kconfig index 1e1cb245fca7..abcaa8da45ac 100644
> >--- a/drivers/gpu/drm/i915/Kconfig
> >+++ b/drivers/gpu/drm/i915/Kconfig
> >@@ -26,6 +26,7 @@ config DRM_I915
> > 	select SND_HDA_I915 if SND_HDA_CORE
> > 	select CEC_CORE if CEC_NOTIFIER
> > 	select VMAP_PFN
> >+	select MFD_CORE
> > 	help
> > 	  Choose this option if you have a system that has "Intel Graphics
> > 	  Media Accelerator" or "HD Graphics" integrated graphics, diff --git
> >a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index
> >235679637d1c..7fa9120feb8d 100644
> >--- a/drivers/gpu/drm/i915/Makefile
> >+++ b/drivers/gpu/drm/i915/Makefile
> >@@ -191,6 +191,9 @@ i915-y += gt/uc/intel_uc.o \
> > 	  gt/uc/intel_huc_debugfs.o \
> > 	  gt/uc/intel_huc_fw.o
> >
> >+# graphics spi device (DGFX) support
> >+i915-y += spi/intel_spi.o
> >+
> > # modesetting core code
> > i915-y += \
> > 	display/intel_atomic.o \
> >diff --git a/drivers/gpu/drm/i915/i915_drv.c
> >b/drivers/gpu/drm/i915/i915_drv.c index 3edd5e47ad68..48c383d37212
> >100644
> >--- a/drivers/gpu/drm/i915/i915_drv.c
> >+++ b/drivers/gpu/drm/i915/i915_drv.c
> >@@ -38,6 +38,7 @@
> > #include <linux/slab.h>
> > #include <linux/vga_switcheroo.h>
> > #include <linux/vt.h>
> >+#include <linux/mfd/core.h>
> >
> > #include <drm/drm_atomic_helper.h>
> > #include <drm/drm_ioctl.h>
> >@@ -67,6 +68,8 @@
> > #include "gt/intel_gt_pm.h"
> > #include "gt/intel_rc6.h"
> >
> >+#include "spi/intel_spi.h"
> >+
> > #include "i915_debugfs.h"
> > #include "i915_drm_client.h"
> > #include "i915_drv.h"
> >@@ -684,6 +687,8 @@ static void i915_driver_register(struct
> >drm_i915_private *dev_priv)
> >
> > 	intel_gt_driver_register(&dev_priv->gt);
> >
> >+	intel_spi_init(&dev_priv->spi, dev_priv);
> >+
> > 	intel_display_driver_register(dev_priv);
> 
> 
> any reason why this is between gt and display init?  I think it would be better
> to call this before gt_driver_register. It doesn't need gt and if eventually
> display also needs to register mfd devices, the unregister counter part of this
> wouldn't be so ackward.

It doesn't really matter, actually gt driver will register additional mfd devices I'm not aware of display mfd devices.

> 
> Naming-wise, most of the functions called here are "*_register()".
> Shouldn't we follow suit and name it intel_spi_driver_register()?

It's not a driver we are initializing but a  device here. If I remember correctly the name was suggested in internal review. 

> 
> >
> > 	intel_power_domains_enable(dev_priv);
> >@@ -710,6 +715,10 @@ static void i915_driver_unregister(struct
> >drm_i915_private *dev_priv)
> >
> > 	intel_display_driver_unregister(dev_priv);
> >
> >+	mfd_remove_devices(&dev_priv->drm.pdev->dev);
> >+
> >+	intel_spi_fini(&dev_priv->spi);
> 
> see below, I don't think we actually need/want this. I'd rather have a
> comment here explaining why we are not "unpeeling the onion" wrt to the
> register function:

The is a result of bad rebase, good catch, the above code is correct. 
> 
> 	/*
> 	 * mfd drivers are added separately, but removed all at once
> 	 * from dev_priv
> 	 */
> 	mfd_remove_devices(&dev_priv->drm.pdev->dev);
> 
> >+
> > 	intel_gt_driver_unregister(&dev_priv->gt);
> >
> > 	i915_perf_unregister(dev_priv);
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >b/drivers/gpu/drm/i915/i915_drv.h index f8413b3b9da8..f12ec7606d75
> >100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -85,6 +85,8 @@
> > #include "gt/intel_workarounds.h"
> > #include "gt/uc/intel_uc.h"
> >
> >+#include "spi/intel_spi.h"
> >+
> > #include "intel_device_info.h"
> > #include "intel_pch.h"
> > #include "intel_runtime_pm.h"
> >@@ -1117,6 +1119,8 @@ struct drm_i915_private {
> >
> > 	struct i915_perf perf;
> >
> >+	struct intel_spi spi;
> >+
> > 	/* Abstract the submission mechanism (legacy ringbuffer or
> execlists) away */
> > 	struct intel_gt gt;
> >
> >diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >b/drivers/gpu/drm/i915/i915_reg.h index 224ad897af34..426c5dd63673
> >100644
> >--- a/drivers/gpu/drm/i915/i915_reg.h
> >+++ b/drivers/gpu/drm/i915/i915_reg.h
> >@@ -2510,6 +2510,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t
> reg)
> > #define VEBOX_RING_BASE		0x1a000
> > #define GEN11_VEBOX_RING_BASE		0x1c8000
> > #define GEN11_VEBOX2_RING_BASE		0x1d8000
> >+#define GEN12_GUNIT_SPI_BASE	0x00102040
> > #define BLT_RING_BASE		0x22000
> > #define RING_TAIL(base)		_MMIO((base) + 0x30)
> > #define RING_HEAD(base)		_MMIO((base) + 0x34)
> >diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
> >b/drivers/gpu/drm/i915/spi/intel_spi.c
> >new file mode 100644
> >index 000000000000..07da7197bd5d
> >--- /dev/null
> >+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
> >@@ -0,0 +1,53 @@
> >+// SPDX-License-Identifier: MIT
> >+/*
> >+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> >+ */
> >+
> >+#include <linux/mfd/core.h>
> >+#include <linux/irq.h>
> >+#include "i915_reg.h"
> >+#include "i915_drv.h"
> >+#include "gt/intel_gt.h"
> >+#include "spi/intel_spi.h"
> >+
> >+static const struct resource spi_resources[] = {
> >+	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-
> spi-mmio"), };
> >+
> >+static const struct mfd_cell intel_spi_cell = {
> >+	.id = 2,
> >+	.name = "i915-spi",
> >+	.num_resources = ARRAY_SIZE(spi_resources),
> >+	.resources = spi_resources,
> >+};
> >+
> >+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private
> >+*dev_priv) {
> >+	struct pci_dev *pdev = dev_priv->drm.pdev;
> >+	int ret;
> >+
> >+	/* Only the DGFX devices have internal SPI */
> >+	if (!IS_DGFX(dev_priv))
> >+		return;
> >+
> >+	ret = mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
> >+			      &intel_spi_cell, 1,
> >+			      &pdev->resource[0], -1, NULL);
> >+
> >+	if (ret)
> >+		dev_err(&pdev->dev, "creating i915-spi cell failed\n");
> >+
> >+	spi->i915 = dev_priv;
> >+}
> >+
> >+void intel_spi_fini(struct intel_spi *spi) {
> >+	struct pci_dev *pdev;
> >+
> >+	if (!spi->i915)
> >+		return;
> >+
> >+	pdev = spi->i915->drm.pdev;
> >+
> >+	dev_dbg(&pdev->dev, "removing i915-spi cell\n");
> 
> this is actually a NOP. I don't think we actually need it since mfd devices are
> removed all at once from the driver

There was intention to use that code, but it's a leftover I will drop it. 

> 
> >+}
> >diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h
> >b/drivers/gpu/drm/i915/spi/intel_spi.h
> >new file mode 100644
> >index 000000000000..276551fed993
> >--- /dev/null
> >+++ b/drivers/gpu/drm/i915/spi/intel_spi.h
> >@@ -0,0 +1,19 @@
> >+/* SPDX-License-Identifier: MIT */
> >+/*
> >+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> >+ */
> >+
> >+#ifndef __INTEL_SPI_DEV_H__
> >+#define __INTEL_SPI_DEV_H__
> >+
> >+struct drm_i915_private;
> >+
> >+struct intel_spi {
> >+	struct drm_i915_private *i915;
> >+};
> >+
> >+void intel_spi_init(struct intel_spi *spi, struct drm_i915_private
> >+*i915);
> >+
> >+void intel_spi_fini(struct intel_spi *spi);
> >+
> >+#endif /* __INTEL_SPI_DEV_H__ */
> >--
> >2.26.2
> >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFC PATCH 2/9] drm/i915/spi: intel_spi_region map

[Tomas Winkler]

Add the dGFX spi region map and convey it via mfd cell platform data
to the spi child device.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi.c | 9 +++++++++
 drivers/gpu/drm/i915/spi/intel_spi.h | 5 +++++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c b/drivers/gpu/drm/i915/spi/intel_spi.c
index 07da7197bd5d..6f83f24f7208 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
@@ -14,11 +14,20 @@ static const struct resource spi_resources[] = {
 	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-spi-mmio"),
 };
 
+static const struct i915_spi_region regions[I915_SPI_REGIONS] = {
+	[0] = { .name = "DESCRIPTOR", },
+	[2] = { .name = "GSC", },
+	[11] = { .name = "OptionROM", },
+	[12] = { .name = "DAM", },
+};
+
 static const struct mfd_cell intel_spi_cell = {
 	.id = 2,
 	.name = "i915-spi",
 	.num_resources = ARRAY_SIZE(spi_resources),
 	.resources = spi_resources,
+	.platform_data = (void *)regions,
+	.pdata_size    = sizeof(regions),
 };
 
 void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h b/drivers/gpu/drm/i915/spi/intel_spi.h
index 276551fed993..6b5bf053f7d3 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi.h
+++ b/drivers/gpu/drm/i915/spi/intel_spi.h
@@ -8,6 +8,11 @@
 
 struct drm_i915_private;
 
+#define I915_SPI_REGIONS 13
+struct i915_spi_region {
+	const char *name;
+};
+
 struct intel_spi {
 	struct drm_i915_private *i915;
 };
-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[Intel-gfx] [RFC PATCH 2/9] drm/i915/spi: intel_spi_region map

[Tomas Winkler]

Add the dGFX spi region map and convey it via mfd cell platform data
to the spi child device.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi.c | 9 +++++++++
 drivers/gpu/drm/i915/spi/intel_spi.h | 5 +++++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c b/drivers/gpu/drm/i915/spi/intel_spi.c
index 07da7197bd5d..6f83f24f7208 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
@@ -14,11 +14,20 @@ static const struct resource spi_resources[] = {
 	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-spi-mmio"),
 };
 
+static const struct i915_spi_region regions[I915_SPI_REGIONS] = {
+	[0] = { .name = "DESCRIPTOR", },
+	[2] = { .name = "GSC", },
+	[11] = { .name = "OptionROM", },
+	[12] = { .name = "DAM", },
+};
+
 static const struct mfd_cell intel_spi_cell = {
 	.id = 2,
 	.name = "i915-spi",
 	.num_resources = ARRAY_SIZE(spi_resources),
 	.resources = spi_resources,
+	.platform_data = (void *)regions,
+	.pdata_size    = sizeof(regions),
 };
 
 void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h b/drivers/gpu/drm/i915/spi/intel_spi.h
index 276551fed993..6b5bf053f7d3 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi.h
+++ b/drivers/gpu/drm/i915/spi/intel_spi.h
@@ -8,6 +8,11 @@
 
 struct drm_i915_private;
 
+#define I915_SPI_REGIONS 13
+struct i915_spi_region {
+	const char *name;
+};
+
 struct intel_spi {
 	struct drm_i915_private *i915;
 };
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH 2/9] drm/i915/spi: intel_spi_region map

[Jani Nikula]

On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> Add the dGFX spi region map and convey it via mfd cell platform data
> to the spi child device.
>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> ---
>  drivers/gpu/drm/i915/spi/intel_spi.c | 9 +++++++++
>  drivers/gpu/drm/i915/spi/intel_spi.h | 5 +++++
>  2 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c b/drivers/gpu/drm/i915/spi/intel_spi.c
> index 07da7197bd5d..6f83f24f7208 100644
> --- a/drivers/gpu/drm/i915/spi/intel_spi.c
> +++ b/drivers/gpu/drm/i915/spi/intel_spi.c
> @@ -14,11 +14,20 @@ static const struct resource spi_resources[] = {
>  	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-spi-mmio"),
>  };
>  
> +static const struct i915_spi_region regions[I915_SPI_REGIONS] = {
> +	[0] = { .name = "DESCRIPTOR", },
> +	[2] = { .name = "GSC", },
> +	[11] = { .name = "OptionROM", },
> +	[12] = { .name = "DAM", },
> +};
> +
>  static const struct mfd_cell intel_spi_cell = {
>  	.id = 2,
>  	.name = "i915-spi",
>  	.num_resources = ARRAY_SIZE(spi_resources),
>  	.resources = spi_resources,
> +	.platform_data = (void *)regions,
> +	.pdata_size    = sizeof(regions),
>  };
>  
>  void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h b/drivers/gpu/drm/i915/spi/intel_spi.h
> index 276551fed993..6b5bf053f7d3 100644
> --- a/drivers/gpu/drm/i915/spi/intel_spi.h
> +++ b/drivers/gpu/drm/i915/spi/intel_spi.h
> @@ -8,6 +8,11 @@
>  
>  struct drm_i915_private;
>  
> +#define I915_SPI_REGIONS 13
> +struct i915_spi_region {
> +	const char *name;
> +};

Does this need to be exposed to the rest of i915? If we're trying to
isolate spi/, I'd prefer it if this header was the only header included
from the rest of i915, and contained the minimum required information.

As the driver has grown bigger, we've tried to minimize the
interconnections between the modules, and it's slow going. Let's try to
keep the new parts isolated.

BR,
Jani.

> +
>  struct intel_spi {
>  	struct drm_i915_private *i915;
>  };

-- 
Jani Nikula, Intel Open Source Graphics Center

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 2/9] drm/i915/spi: intel_spi_region map

[Jani Nikula]

On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> Add the dGFX spi region map and convey it via mfd cell platform data
> to the spi child device.
>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> ---
>  drivers/gpu/drm/i915/spi/intel_spi.c | 9 +++++++++
>  drivers/gpu/drm/i915/spi/intel_spi.h | 5 +++++
>  2 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c b/drivers/gpu/drm/i915/spi/intel_spi.c
> index 07da7197bd5d..6f83f24f7208 100644
> --- a/drivers/gpu/drm/i915/spi/intel_spi.c
> +++ b/drivers/gpu/drm/i915/spi/intel_spi.c
> @@ -14,11 +14,20 @@ static const struct resource spi_resources[] = {
>  	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-spi-mmio"),
>  };
>  
> +static const struct i915_spi_region regions[I915_SPI_REGIONS] = {
> +	[0] = { .name = "DESCRIPTOR", },
> +	[2] = { .name = "GSC", },
> +	[11] = { .name = "OptionROM", },
> +	[12] = { .name = "DAM", },
> +};
> +
>  static const struct mfd_cell intel_spi_cell = {
>  	.id = 2,
>  	.name = "i915-spi",
>  	.num_resources = ARRAY_SIZE(spi_resources),
>  	.resources = spi_resources,
> +	.platform_data = (void *)regions,
> +	.pdata_size    = sizeof(regions),
>  };
>  
>  void intel_spi_init(struct intel_spi *spi, struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h b/drivers/gpu/drm/i915/spi/intel_spi.h
> index 276551fed993..6b5bf053f7d3 100644
> --- a/drivers/gpu/drm/i915/spi/intel_spi.h
> +++ b/drivers/gpu/drm/i915/spi/intel_spi.h
> @@ -8,6 +8,11 @@
>  
>  struct drm_i915_private;
>  
> +#define I915_SPI_REGIONS 13
> +struct i915_spi_region {
> +	const char *name;
> +};

Does this need to be exposed to the rest of i915? If we're trying to
isolate spi/, I'd prefer it if this header was the only header included
from the rest of i915, and contained the minimum required information.

As the driver has grown bigger, we've tried to minimize the
interconnections between the modules, and it's slow going. Let's try to
keep the new parts isolated.

BR,
Jani.

> +
>  struct intel_spi {
>  	struct drm_i915_private *i915;
>  };

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 2/9] drm/i915/spi: intel_spi_region map

[Winkler, Tomas]

> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> > Add the dGFX spi region map and convey it via mfd cell platform data
> > to the spi child device.
> >
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > ---
> >  drivers/gpu/drm/i915/spi/intel_spi.c | 9 +++++++++
> > drivers/gpu/drm/i915/spi/intel_spi.h | 5 +++++
> >  2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
> > b/drivers/gpu/drm/i915/spi/intel_spi.c
> > index 07da7197bd5d..6f83f24f7208 100644
> > --- a/drivers/gpu/drm/i915/spi/intel_spi.c
> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.c
> > @@ -14,11 +14,20 @@ static const struct resource spi_resources[] = {
> >  	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-
> spi-mmio"),
> > };
> >
> > +static const struct i915_spi_region regions[I915_SPI_REGIONS] = {
> > +	[0] = { .name = "DESCRIPTOR", },
> > +	[2] = { .name = "GSC", },
> > +	[11] = { .name = "OptionROM", },
> > +	[12] = { .name = "DAM", },
> > +};
> > +
> >  static const struct mfd_cell intel_spi_cell = {
> >  	.id = 2,
> >  	.name = "i915-spi",
> >  	.num_resources = ARRAY_SIZE(spi_resources),
> >  	.resources = spi_resources,
> > +	.platform_data = (void *)regions,
> > +	.pdata_size    = sizeof(regions),
> >  };
> >
> >  void intel_spi_init(struct intel_spi *spi, struct drm_i915_private
> > *dev_priv) diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h
> > b/drivers/gpu/drm/i915/spi/intel_spi.h
> > index 276551fed993..6b5bf053f7d3 100644
> > --- a/drivers/gpu/drm/i915/spi/intel_spi.h
> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.h
> > @@ -8,6 +8,11 @@
> >
> >  struct drm_i915_private;
> >
> > +#define I915_SPI_REGIONS 13
> > +struct i915_spi_region {
> > +	const char *name;
> > +};
> 
> Does this need to be exposed to the rest of i915? 
This part is between the device which is part of i915 and the driver.
>If we're trying to isolate
> spi/, I'd prefer it if this header was the only header included from the rest of
> i915, and contained the minimum required information.

> As the driver has grown bigger, we've tried to minimize the interconnections
> between the modules, and it's slow going. Let's try to keep the new parts
> isolated.
>
So do you prefer we create another header or duplicate the structure definition? 

Thanks
Tomas


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 2/9] drm/i915/spi: intel_spi_region map

[Winkler, Tomas]

> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> > Add the dGFX spi region map and convey it via mfd cell platform data
> > to the spi child device.
> >
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > ---
> >  drivers/gpu/drm/i915/spi/intel_spi.c | 9 +++++++++
> > drivers/gpu/drm/i915/spi/intel_spi.h | 5 +++++
> >  2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
> > b/drivers/gpu/drm/i915/spi/intel_spi.c
> > index 07da7197bd5d..6f83f24f7208 100644
> > --- a/drivers/gpu/drm/i915/spi/intel_spi.c
> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.c
> > @@ -14,11 +14,20 @@ static const struct resource spi_resources[] = {
> >  	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-
> spi-mmio"),
> > };
> >
> > +static const struct i915_spi_region regions[I915_SPI_REGIONS] = {
> > +	[0] = { .name = "DESCRIPTOR", },
> > +	[2] = { .name = "GSC", },
> > +	[11] = { .name = "OptionROM", },
> > +	[12] = { .name = "DAM", },
> > +};
> > +
> >  static const struct mfd_cell intel_spi_cell = {
> >  	.id = 2,
> >  	.name = "i915-spi",
> >  	.num_resources = ARRAY_SIZE(spi_resources),
> >  	.resources = spi_resources,
> > +	.platform_data = (void *)regions,
> > +	.pdata_size    = sizeof(regions),
> >  };
> >
> >  void intel_spi_init(struct intel_spi *spi, struct drm_i915_private
> > *dev_priv) diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h
> > b/drivers/gpu/drm/i915/spi/intel_spi.h
> > index 276551fed993..6b5bf053f7d3 100644
> > --- a/drivers/gpu/drm/i915/spi/intel_spi.h
> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.h
> > @@ -8,6 +8,11 @@
> >
> >  struct drm_i915_private;
> >
> > +#define I915_SPI_REGIONS 13
> > +struct i915_spi_region {
> > +	const char *name;
> > +};
> 
> Does this need to be exposed to the rest of i915? 
This part is between the device which is part of i915 and the driver.
>If we're trying to isolate
> spi/, I'd prefer it if this header was the only header included from the rest of
> i915, and contained the minimum required information.

> As the driver has grown bigger, we've tried to minimize the interconnections
> between the modules, and it's slow going. Let's try to keep the new parts
> isolated.
>
So do you prefer we create another header or duplicate the structure definition? 

Thanks
Tomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 2/9] drm/i915/spi: intel_spi_region map

[Jani Nikula]

On Wed, 17 Feb 2021, "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
>> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> > Add the dGFX spi region map and convey it via mfd cell platform data
>> > to the spi child device.
>> >
>> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/spi/intel_spi.c | 9 +++++++++
>> > drivers/gpu/drm/i915/spi/intel_spi.h | 5 +++++
>> >  2 files changed, 14 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
>> > b/drivers/gpu/drm/i915/spi/intel_spi.c
>> > index 07da7197bd5d..6f83f24f7208 100644
>> > --- a/drivers/gpu/drm/i915/spi/intel_spi.c
>> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.c
>> > @@ -14,11 +14,20 @@ static const struct resource spi_resources[] = {
>> >  	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-
>> spi-mmio"),
>> > };
>> >
>> > +static const struct i915_spi_region regions[I915_SPI_REGIONS] = {
>> > +	[0] = { .name = "DESCRIPTOR", },
>> > +	[2] = { .name = "GSC", },
>> > +	[11] = { .name = "OptionROM", },
>> > +	[12] = { .name = "DAM", },
>> > +};
>> > +
>> >  static const struct mfd_cell intel_spi_cell = {
>> >  	.id = 2,
>> >  	.name = "i915-spi",
>> >  	.num_resources = ARRAY_SIZE(spi_resources),
>> >  	.resources = spi_resources,
>> > +	.platform_data = (void *)regions,
>> > +	.pdata_size    = sizeof(regions),
>> >  };
>> >
>> >  void intel_spi_init(struct intel_spi *spi, struct drm_i915_private
>> > *dev_priv) diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h
>> > b/drivers/gpu/drm/i915/spi/intel_spi.h
>> > index 276551fed993..6b5bf053f7d3 100644
>> > --- a/drivers/gpu/drm/i915/spi/intel_spi.h
>> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.h
>> > @@ -8,6 +8,11 @@
>> >
>> >  struct drm_i915_private;
>> >
>> > +#define I915_SPI_REGIONS 13
>> > +struct i915_spi_region {
>> > +	const char *name;
>> > +};
>> 
>> Does this need to be exposed to the rest of i915? 
> This part is between the device which is part of i915 and the driver.
>>If we're trying to isolate
>> spi/, I'd prefer it if this header was the only header included from the rest of
>> i915, and contained the minimum required information.
>
>> As the driver has grown bigger, we've tried to minimize the interconnections
>> between the modules, and it's slow going. Let's try to keep the new parts
>> isolated.
>>
> So do you prefer we create another header or duplicate the structure definition? 

I didn't see the struct being used in i915, or am I missing something?

Have a header that contains the interface exposed to the rest of i915,
and another header with stuff internal to spi/?

BR,
Jani.




-- 
Jani Nikula, Intel Open Source Graphics Center

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 2/9] drm/i915/spi: intel_spi_region map

[Jani Nikula]

On Wed, 17 Feb 2021, "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
>> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> > Add the dGFX spi region map and convey it via mfd cell platform data
>> > to the spi child device.
>> >
>> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/spi/intel_spi.c | 9 +++++++++
>> > drivers/gpu/drm/i915/spi/intel_spi.h | 5 +++++
>> >  2 files changed, 14 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
>> > b/drivers/gpu/drm/i915/spi/intel_spi.c
>> > index 07da7197bd5d..6f83f24f7208 100644
>> > --- a/drivers/gpu/drm/i915/spi/intel_spi.c
>> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.c
>> > @@ -14,11 +14,20 @@ static const struct resource spi_resources[] = {
>> >  	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-
>> spi-mmio"),
>> > };
>> >
>> > +static const struct i915_spi_region regions[I915_SPI_REGIONS] = {
>> > +	[0] = { .name = "DESCRIPTOR", },
>> > +	[2] = { .name = "GSC", },
>> > +	[11] = { .name = "OptionROM", },
>> > +	[12] = { .name = "DAM", },
>> > +};
>> > +
>> >  static const struct mfd_cell intel_spi_cell = {
>> >  	.id = 2,
>> >  	.name = "i915-spi",
>> >  	.num_resources = ARRAY_SIZE(spi_resources),
>> >  	.resources = spi_resources,
>> > +	.platform_data = (void *)regions,
>> > +	.pdata_size    = sizeof(regions),
>> >  };
>> >
>> >  void intel_spi_init(struct intel_spi *spi, struct drm_i915_private
>> > *dev_priv) diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h
>> > b/drivers/gpu/drm/i915/spi/intel_spi.h
>> > index 276551fed993..6b5bf053f7d3 100644
>> > --- a/drivers/gpu/drm/i915/spi/intel_spi.h
>> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.h
>> > @@ -8,6 +8,11 @@
>> >
>> >  struct drm_i915_private;
>> >
>> > +#define I915_SPI_REGIONS 13
>> > +struct i915_spi_region {
>> > +	const char *name;
>> > +};
>> 
>> Does this need to be exposed to the rest of i915? 
> This part is between the device which is part of i915 and the driver.
>>If we're trying to isolate
>> spi/, I'd prefer it if this header was the only header included from the rest of
>> i915, and contained the minimum required information.
>
>> As the driver has grown bigger, we've tried to minimize the interconnections
>> between the modules, and it's slow going. Let's try to keep the new parts
>> isolated.
>>
> So do you prefer we create another header or duplicate the structure definition? 

I didn't see the struct being used in i915, or am I missing something?

Have a header that contains the interface exposed to the rest of i915,
and another header with stuff internal to spi/?

BR,
Jani.




-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 2/9] drm/i915/spi: intel_spi_region map

[Winkler, Tomas]

> On Wed, 17 Feb 2021, "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> >> > Add the dGFX spi region map and convey it via mfd cell platform
> >> > data to the spi child device.
> >> >
> >> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> >> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> >> > ---
> >> >  drivers/gpu/drm/i915/spi/intel_spi.c | 9 +++++++++
> >> > drivers/gpu/drm/i915/spi/intel_spi.h | 5 +++++
> >> >  2 files changed, 14 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
> >> > b/drivers/gpu/drm/i915/spi/intel_spi.c
> >> > index 07da7197bd5d..6f83f24f7208 100644
> >> > --- a/drivers/gpu/drm/i915/spi/intel_spi.c
> >> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.c
> >> > @@ -14,11 +14,20 @@ static const struct resource spi_resources[] = {
> >> >  	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-
> >> spi-mmio"),
> >> > };
> >> >
> >> > +static const struct i915_spi_region regions[I915_SPI_REGIONS] = {
> >> > +	[0] = { .name = "DESCRIPTOR", },
> >> > +	[2] = { .name = "GSC", },
> >> > +	[11] = { .name = "OptionROM", },
> >> > +	[12] = { .name = "DAM", },
> >> > +};
> >> > +
> >> >  static const struct mfd_cell intel_spi_cell = {
> >> >  	.id = 2,
> >> >  	.name = "i915-spi",
> >> >  	.num_resources = ARRAY_SIZE(spi_resources),
> >> >  	.resources = spi_resources,
> >> > +	.platform_data = (void *)regions,
> >> > +	.pdata_size    = sizeof(regions),
> >> >  };
> >> >
> >> >  void intel_spi_init(struct intel_spi *spi, struct drm_i915_private
> >> > *dev_priv) diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h
> >> > b/drivers/gpu/drm/i915/spi/intel_spi.h
> >> > index 276551fed993..6b5bf053f7d3 100644
> >> > --- a/drivers/gpu/drm/i915/spi/intel_spi.h
> >> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.h
> >> > @@ -8,6 +8,11 @@
> >> >
> >> >  struct drm_i915_private;
> >> >
> >> > +#define I915_SPI_REGIONS 13
> >> > +struct i915_spi_region {
> >> > +	const char *name;
> >> > +};
> >>
> >> Does this need to be exposed to the rest of i915?
> > This part is between the device which is part of i915 and the driver.
> >>If we're trying to isolate
> >> spi/, I'd prefer it if this header was the only header included from
> >>the rest of  i915, and contained the minimum required information.
> >
> >> As the driver has grown bigger, we've tried to minimize the
> >> interconnections between the modules, and it's slow going. Let's try
> >> to keep the new parts isolated.
> >>
> > So do you prefer we create another header or duplicate the structure
> definition?
> 
> I didn't see the struct being used in i915, or am I missing something?
This file is part of i915
 
> Have a header that contains the interface exposed to the rest of i915, and
> another header with stuff internal to spi/?

The spi `device` is part of i915 (as a mfd cell) and  struct i915_spi_region is  passed to the spi `driver` as platform_data of the device.
In order for driver to be able to understand  it needs to know ' struct i915_spi_region' 

Thanks
Tomas


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 2/9] drm/i915/spi: intel_spi_region map

[Winkler, Tomas]

> On Wed, 17 Feb 2021, "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> >> > Add the dGFX spi region map and convey it via mfd cell platform
> >> > data to the spi child device.
> >> >
> >> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> >> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> >> > ---
> >> >  drivers/gpu/drm/i915/spi/intel_spi.c | 9 +++++++++
> >> > drivers/gpu/drm/i915/spi/intel_spi.h | 5 +++++
> >> >  2 files changed, 14 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
> >> > b/drivers/gpu/drm/i915/spi/intel_spi.c
> >> > index 07da7197bd5d..6f83f24f7208 100644
> >> > --- a/drivers/gpu/drm/i915/spi/intel_spi.c
> >> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.c
> >> > @@ -14,11 +14,20 @@ static const struct resource spi_resources[] = {
> >> >  	DEFINE_RES_MEM_NAMED(GEN12_GUNIT_SPI_BASE, 0x80, "i915-
> >> spi-mmio"),
> >> > };
> >> >
> >> > +static const struct i915_spi_region regions[I915_SPI_REGIONS] = {
> >> > +	[0] = { .name = "DESCRIPTOR", },
> >> > +	[2] = { .name = "GSC", },
> >> > +	[11] = { .name = "OptionROM", },
> >> > +	[12] = { .name = "DAM", },
> >> > +};
> >> > +
> >> >  static const struct mfd_cell intel_spi_cell = {
> >> >  	.id = 2,
> >> >  	.name = "i915-spi",
> >> >  	.num_resources = ARRAY_SIZE(spi_resources),
> >> >  	.resources = spi_resources,
> >> > +	.platform_data = (void *)regions,
> >> > +	.pdata_size    = sizeof(regions),
> >> >  };
> >> >
> >> >  void intel_spi_init(struct intel_spi *spi, struct drm_i915_private
> >> > *dev_priv) diff --git a/drivers/gpu/drm/i915/spi/intel_spi.h
> >> > b/drivers/gpu/drm/i915/spi/intel_spi.h
> >> > index 276551fed993..6b5bf053f7d3 100644
> >> > --- a/drivers/gpu/drm/i915/spi/intel_spi.h
> >> > +++ b/drivers/gpu/drm/i915/spi/intel_spi.h
> >> > @@ -8,6 +8,11 @@
> >> >
> >> >  struct drm_i915_private;
> >> >
> >> > +#define I915_SPI_REGIONS 13
> >> > +struct i915_spi_region {
> >> > +	const char *name;
> >> > +};
> >>
> >> Does this need to be exposed to the rest of i915?
> > This part is between the device which is part of i915 and the driver.
> >>If we're trying to isolate
> >> spi/, I'd prefer it if this header was the only header included from
> >>the rest of  i915, and contained the minimum required information.
> >
> >> As the driver has grown bigger, we've tried to minimize the
> >> interconnections between the modules, and it's slow going. Let's try
> >> to keep the new parts isolated.
> >>
> > So do you prefer we create another header or duplicate the structure
> definition?
> 
> I didn't see the struct being used in i915, or am I missing something?
This file is part of i915
 
> Have a header that contains the interface exposed to the rest of i915, and
> another header with stuff internal to spi/?

The spi `device` is part of i915 (as a mfd cell) and  struct i915_spi_region is  passed to the spi `driver` as platform_data of the device.
In order for driver to be able to understand  it needs to know ' struct i915_spi_region' 

Thanks
Tomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Tomas Winkler]

Add the platform driver for i915 on-die spi device, exposed via mfd
framework.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/Kconfig             |   2 +
 drivers/gpu/drm/i915/Makefile            |   3 +
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116 +++++++++++++++++++++++
 3 files changed, 121 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index abcaa8da45ac..13c870e5878e 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -27,6 +27,8 @@ config DRM_I915
 	select CEC_CORE if CEC_NOTIFIER
 	select VMAP_PFN
 	select MFD_CORE
+	select MTD
+	select MTD_PARTITIONED_MASTER
 	help
 	  Choose this option if you have a system that has "Intel Graphics
 	  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7fa9120feb8d..f209cd541eec 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -299,6 +299,9 @@ endif
 obj-$(CONFIG_DRM_I915) += i915.o
 obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
 
+obj-m += i915_spi.o
+i915_spi-y := spi/intel_spi_drv.o
+
 # header test
 
 # exclude some broken headers from the test coverage
diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
new file mode 100644
index 000000000000..23261f35b71f
--- /dev/null
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
+ */
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/io.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <spi/intel_spi.h>
+
+struct i915_spi {
+	void __iomem *base;
+	size_t size;
+	unsigned int nregions;
+	struct {
+		const char *name;
+		u8 id;
+		u64 offset;
+		u64 size;
+	} regions[];
+};
+
+static int i915_spi_probe(struct platform_device *platdev)
+{
+	struct resource *bar;
+	struct device *device;
+	struct i915_spi *spi;
+	struct i915_spi_region *regions;
+	unsigned int nregions;
+	unsigned int i, n;
+	size_t size;
+	char *name;
+	size_t name_size;
+
+	device = &platdev->dev;
+
+	regions = dev_get_platdata(&platdev->dev);
+	if (!regions) {
+		dev_err(device, "no regions defined\n");
+		return -ENODEV;
+	}
+
+	/* count available regions */
+	for (nregions = 0, i = 0; i < I915_SPI_REGIONS; i++) {
+		if (regions[i].name)
+			nregions++;
+	}
+
+	if (!nregions) {
+		dev_err(device, "no regions defined\n");
+		return -ENODEV;
+	}
+
+	size = sizeof(*spi) + sizeof(spi->regions[0]) * nregions;
+	spi = devm_kzalloc(device, size, GFP_KERNEL);
+	if (!spi)
+		return -ENOMEM;
+
+	spi->nregions = nregions;
+	for (n = 0, i = 0; i < I915_SPI_REGIONS; i++) {
+		if (regions[i].name) {
+			name_size = strlen(dev_name(&platdev->dev)) +
+				    strlen(regions[i].name) + 2; /* for point */
+			name = devm_kzalloc(device, name_size, GFP_KERNEL);
+			if (!name)
+				continue;
+			snprintf(name, name_size, "%s.%s",
+				 dev_name(&platdev->dev), regions[i].name);
+			spi->regions[n].name = name;
+			spi->regions[n].id = i;
+			n++;
+		}
+	}
+
+	bar = platform_get_resource(platdev, IORESOURCE_MEM, 0);
+	if (!bar)
+		return -ENODEV;
+
+	spi->base = devm_ioremap_resource(device, bar);
+	if (IS_ERR(spi->base)) {
+		dev_err(device, "mmio not mapped\n");
+		return PTR_ERR(spi->base);
+	}
+
+	platform_set_drvdata(platdev, spi);
+
+	dev_dbg(device, "i915-spi is bound\n");
+
+	return 0;
+}
+
+static int i915_spi_remove(struct platform_device *platdev)
+{
+	platform_set_drvdata(platdev, NULL);
+
+	return 0;
+}
+
+MODULE_ALIAS("platform:i915-spi");
+static struct platform_driver i915_spi_driver = {
+	.probe  = i915_spi_probe,
+	.remove = i915_spi_remove,
+	.driver = {
+		.name = "i915-spi",
+	},
+};
+
+module_platform_driver(i915_spi_driver);
+
+MODULE_LICENSE("GPL and additional rights");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_DESCRIPTION("Intel DGFX SPI driver");
-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Tomas Winkler]

Add the platform driver for i915 on-die spi device, exposed via mfd
framework.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/Kconfig             |   2 +
 drivers/gpu/drm/i915/Makefile            |   3 +
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116 +++++++++++++++++++++++
 3 files changed, 121 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index abcaa8da45ac..13c870e5878e 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -27,6 +27,8 @@ config DRM_I915
 	select CEC_CORE if CEC_NOTIFIER
 	select VMAP_PFN
 	select MFD_CORE
+	select MTD
+	select MTD_PARTITIONED_MASTER
 	help
 	  Choose this option if you have a system that has "Intel Graphics
 	  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7fa9120feb8d..f209cd541eec 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -299,6 +299,9 @@ endif
 obj-$(CONFIG_DRM_I915) += i915.o
 obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
 
+obj-m += i915_spi.o
+i915_spi-y := spi/intel_spi_drv.o
+
 # header test
 
 # exclude some broken headers from the test coverage
diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
new file mode 100644
index 000000000000..23261f35b71f
--- /dev/null
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
+ */
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/io.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <spi/intel_spi.h>
+
+struct i915_spi {
+	void __iomem *base;
+	size_t size;
+	unsigned int nregions;
+	struct {
+		const char *name;
+		u8 id;
+		u64 offset;
+		u64 size;
+	} regions[];
+};
+
+static int i915_spi_probe(struct platform_device *platdev)
+{
+	struct resource *bar;
+	struct device *device;
+	struct i915_spi *spi;
+	struct i915_spi_region *regions;
+	unsigned int nregions;
+	unsigned int i, n;
+	size_t size;
+	char *name;
+	size_t name_size;
+
+	device = &platdev->dev;
+
+	regions = dev_get_platdata(&platdev->dev);
+	if (!regions) {
+		dev_err(device, "no regions defined\n");
+		return -ENODEV;
+	}
+
+	/* count available regions */
+	for (nregions = 0, i = 0; i < I915_SPI_REGIONS; i++) {
+		if (regions[i].name)
+			nregions++;
+	}
+
+	if (!nregions) {
+		dev_err(device, "no regions defined\n");
+		return -ENODEV;
+	}
+
+	size = sizeof(*spi) + sizeof(spi->regions[0]) * nregions;
+	spi = devm_kzalloc(device, size, GFP_KERNEL);
+	if (!spi)
+		return -ENOMEM;
+
+	spi->nregions = nregions;
+	for (n = 0, i = 0; i < I915_SPI_REGIONS; i++) {
+		if (regions[i].name) {
+			name_size = strlen(dev_name(&platdev->dev)) +
+				    strlen(regions[i].name) + 2; /* for point */
+			name = devm_kzalloc(device, name_size, GFP_KERNEL);
+			if (!name)
+				continue;
+			snprintf(name, name_size, "%s.%s",
+				 dev_name(&platdev->dev), regions[i].name);
+			spi->regions[n].name = name;
+			spi->regions[n].id = i;
+			n++;
+		}
+	}
+
+	bar = platform_get_resource(platdev, IORESOURCE_MEM, 0);
+	if (!bar)
+		return -ENODEV;
+
+	spi->base = devm_ioremap_resource(device, bar);
+	if (IS_ERR(spi->base)) {
+		dev_err(device, "mmio not mapped\n");
+		return PTR_ERR(spi->base);
+	}
+
+	platform_set_drvdata(platdev, spi);
+
+	dev_dbg(device, "i915-spi is bound\n");
+
+	return 0;
+}
+
+static int i915_spi_remove(struct platform_device *platdev)
+{
+	platform_set_drvdata(platdev, NULL);
+
+	return 0;
+}
+
+MODULE_ALIAS("platform:i915-spi");
+static struct platform_driver i915_spi_driver = {
+	.probe  = i915_spi_probe,
+	.remove = i915_spi_remove,
+	.driver = {
+		.name = "i915-spi",
+	},
+};
+
+module_platform_driver(i915_spi_driver);
+
+MODULE_LICENSE("GPL and additional rights");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_DESCRIPTION("Intel DGFX SPI driver");
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Jani Nikula]

On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> Add the platform driver for i915 on-die spi device, exposed via mfd
> framework.
>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> ---
>  drivers/gpu/drm/i915/Kconfig             |   2 +
>  drivers/gpu/drm/i915/Makefile            |   3 +
>  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116 +++++++++++++++++++++++
>  3 files changed, 121 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index abcaa8da45ac..13c870e5878e 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -27,6 +27,8 @@ config DRM_I915
>  	select CEC_CORE if CEC_NOTIFIER
>  	select VMAP_PFN
>  	select MFD_CORE
> +	select MTD

Selecting MTD does not seem to be a popular thing to do, which is
usually a clue it's probably the wrong thing to do.

> +	select MTD_PARTITIONED_MASTER
>  	help
>  	  Choose this option if you have a system that has "Intel Graphics
>  	  Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 7fa9120feb8d..f209cd541eec 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -299,6 +299,9 @@ endif
>  obj-$(CONFIG_DRM_I915) += i915.o
>  obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
>  
> +obj-m += i915_spi.o

And literally nobody does this.

> +i915_spi-y := spi/intel_spi_drv.o

Time to add a separate Kconfig and Makefile in spi/?

BR,
Jani.

> +
>  # header test
>  
>  # exclude some broken headers from the test coverage
> diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
> new file mode 100644
> index 000000000000..23261f35b71f
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
> @@ -0,0 +1,116 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> + */
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/string.h>
> +#include <linux/io.h>
> +#include <linux/device.h>
> +#include <linux/slab.h>
> +#include <linux/platform_device.h>
> +#include <spi/intel_spi.h>

Should this have "" instead of <>?

> +
> +struct i915_spi {
> +	void __iomem *base;
> +	size_t size;
> +	unsigned int nregions;
> +	struct {
> +		const char *name;
> +		u8 id;
> +		u64 offset;
> +		u64 size;
> +	} regions[];
> +};
> +
> +static int i915_spi_probe(struct platform_device *platdev)
> +{
> +	struct resource *bar;
> +	struct device *device;
> +	struct i915_spi *spi;
> +	struct i915_spi_region *regions;
> +	unsigned int nregions;
> +	unsigned int i, n;
> +	size_t size;
> +	char *name;
> +	size_t name_size;
> +
> +	device = &platdev->dev;
> +
> +	regions = dev_get_platdata(&platdev->dev);
> +	if (!regions) {
> +		dev_err(device, "no regions defined\n");
> +		return -ENODEV;
> +	}
> +
> +	/* count available regions */
> +	for (nregions = 0, i = 0; i < I915_SPI_REGIONS; i++) {
> +		if (regions[i].name)
> +			nregions++;
> +	}
> +
> +	if (!nregions) {
> +		dev_err(device, "no regions defined\n");
> +		return -ENODEV;
> +	}
> +
> +	size = sizeof(*spi) + sizeof(spi->regions[0]) * nregions;
> +	spi = devm_kzalloc(device, size, GFP_KERNEL);
> +	if (!spi)
> +		return -ENOMEM;
> +
> +	spi->nregions = nregions;
> +	for (n = 0, i = 0; i < I915_SPI_REGIONS; i++) {
> +		if (regions[i].name) {
> +			name_size = strlen(dev_name(&platdev->dev)) +
> +				    strlen(regions[i].name) + 2; /* for point */
> +			name = devm_kzalloc(device, name_size, GFP_KERNEL);
> +			if (!name)
> +				continue;
> +			snprintf(name, name_size, "%s.%s",
> +				 dev_name(&platdev->dev), regions[i].name);
> +			spi->regions[n].name = name;
> +			spi->regions[n].id = i;
> +			n++;
> +		}
> +	}
> +
> +	bar = platform_get_resource(platdev, IORESOURCE_MEM, 0);
> +	if (!bar)
> +		return -ENODEV;
> +
> +	spi->base = devm_ioremap_resource(device, bar);
> +	if (IS_ERR(spi->base)) {
> +		dev_err(device, "mmio not mapped\n");
> +		return PTR_ERR(spi->base);
> +	}
> +
> +	platform_set_drvdata(platdev, spi);
> +
> +	dev_dbg(device, "i915-spi is bound\n");
> +
> +	return 0;
> +}
> +
> +static int i915_spi_remove(struct platform_device *platdev)
> +{
> +	platform_set_drvdata(platdev, NULL);
> +
> +	return 0;
> +}
> +
> +MODULE_ALIAS("platform:i915-spi");
> +static struct platform_driver i915_spi_driver = {
> +	.probe  = i915_spi_probe,
> +	.remove = i915_spi_remove,
> +	.driver = {
> +		.name = "i915-spi",
> +	},
> +};
> +
> +module_platform_driver(i915_spi_driver);
> +
> +MODULE_LICENSE("GPL and additional rights");
> +MODULE_AUTHOR("Intel Corporation");
> +MODULE_DESCRIPTION("Intel DGFX SPI driver");

-- 
Jani Nikula, Intel Open Source Graphics Center

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Jani Nikula]

On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> Add the platform driver for i915 on-die spi device, exposed via mfd
> framework.
>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> ---
>  drivers/gpu/drm/i915/Kconfig             |   2 +
>  drivers/gpu/drm/i915/Makefile            |   3 +
>  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116 +++++++++++++++++++++++
>  3 files changed, 121 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index abcaa8da45ac..13c870e5878e 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -27,6 +27,8 @@ config DRM_I915
>  	select CEC_CORE if CEC_NOTIFIER
>  	select VMAP_PFN
>  	select MFD_CORE
> +	select MTD

Selecting MTD does not seem to be a popular thing to do, which is
usually a clue it's probably the wrong thing to do.

> +	select MTD_PARTITIONED_MASTER
>  	help
>  	  Choose this option if you have a system that has "Intel Graphics
>  	  Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 7fa9120feb8d..f209cd541eec 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -299,6 +299,9 @@ endif
>  obj-$(CONFIG_DRM_I915) += i915.o
>  obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
>  
> +obj-m += i915_spi.o

And literally nobody does this.

> +i915_spi-y := spi/intel_spi_drv.o

Time to add a separate Kconfig and Makefile in spi/?

BR,
Jani.

> +
>  # header test
>  
>  # exclude some broken headers from the test coverage
> diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
> new file mode 100644
> index 000000000000..23261f35b71f
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
> @@ -0,0 +1,116 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> + */
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/string.h>
> +#include <linux/io.h>
> +#include <linux/device.h>
> +#include <linux/slab.h>
> +#include <linux/platform_device.h>
> +#include <spi/intel_spi.h>

Should this have "" instead of <>?

> +
> +struct i915_spi {
> +	void __iomem *base;
> +	size_t size;
> +	unsigned int nregions;
> +	struct {
> +		const char *name;
> +		u8 id;
> +		u64 offset;
> +		u64 size;
> +	} regions[];
> +};
> +
> +static int i915_spi_probe(struct platform_device *platdev)
> +{
> +	struct resource *bar;
> +	struct device *device;
> +	struct i915_spi *spi;
> +	struct i915_spi_region *regions;
> +	unsigned int nregions;
> +	unsigned int i, n;
> +	size_t size;
> +	char *name;
> +	size_t name_size;
> +
> +	device = &platdev->dev;
> +
> +	regions = dev_get_platdata(&platdev->dev);
> +	if (!regions) {
> +		dev_err(device, "no regions defined\n");
> +		return -ENODEV;
> +	}
> +
> +	/* count available regions */
> +	for (nregions = 0, i = 0; i < I915_SPI_REGIONS; i++) {
> +		if (regions[i].name)
> +			nregions++;
> +	}
> +
> +	if (!nregions) {
> +		dev_err(device, "no regions defined\n");
> +		return -ENODEV;
> +	}
> +
> +	size = sizeof(*spi) + sizeof(spi->regions[0]) * nregions;
> +	spi = devm_kzalloc(device, size, GFP_KERNEL);
> +	if (!spi)
> +		return -ENOMEM;
> +
> +	spi->nregions = nregions;
> +	for (n = 0, i = 0; i < I915_SPI_REGIONS; i++) {
> +		if (regions[i].name) {
> +			name_size = strlen(dev_name(&platdev->dev)) +
> +				    strlen(regions[i].name) + 2; /* for point */
> +			name = devm_kzalloc(device, name_size, GFP_KERNEL);
> +			if (!name)
> +				continue;
> +			snprintf(name, name_size, "%s.%s",
> +				 dev_name(&platdev->dev), regions[i].name);
> +			spi->regions[n].name = name;
> +			spi->regions[n].id = i;
> +			n++;
> +		}
> +	}
> +
> +	bar = platform_get_resource(platdev, IORESOURCE_MEM, 0);
> +	if (!bar)
> +		return -ENODEV;
> +
> +	spi->base = devm_ioremap_resource(device, bar);
> +	if (IS_ERR(spi->base)) {
> +		dev_err(device, "mmio not mapped\n");
> +		return PTR_ERR(spi->base);
> +	}
> +
> +	platform_set_drvdata(platdev, spi);
> +
> +	dev_dbg(device, "i915-spi is bound\n");
> +
> +	return 0;
> +}
> +
> +static int i915_spi_remove(struct platform_device *platdev)
> +{
> +	platform_set_drvdata(platdev, NULL);
> +
> +	return 0;
> +}
> +
> +MODULE_ALIAS("platform:i915-spi");
> +static struct platform_driver i915_spi_driver = {
> +	.probe  = i915_spi_probe,
> +	.remove = i915_spi_remove,
> +	.driver = {
> +		.name = "i915-spi",
> +	},
> +};
> +
> +module_platform_driver(i915_spi_driver);
> +
> +MODULE_LICENSE("GPL and additional rights");
> +MODULE_AUTHOR("Intel Corporation");
> +MODULE_DESCRIPTION("Intel DGFX SPI driver");

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Winkler, Tomas]

> 
> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> > Add the platform driver for i915 on-die spi device, exposed via mfd
> > framework.
> >
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > ---
> >  drivers/gpu/drm/i915/Kconfig             |   2 +
> >  drivers/gpu/drm/i915/Makefile            |   3 +
> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
> > +++++++++++++++++++++++
> >  3 files changed, 121 insertions(+)
> >  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c
> >
> > diff --git a/drivers/gpu/drm/i915/Kconfig
> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e 100644
> > --- a/drivers/gpu/drm/i915/Kconfig
> > +++ b/drivers/gpu/drm/i915/Kconfig
> > @@ -27,6 +27,8 @@ config DRM_I915
> >  	select CEC_CORE if CEC_NOTIFIER
> >  	select VMAP_PFN
> >  	select MFD_CORE
> > +	select MTD
> 
> Selecting MTD does not seem to be a popular thing to do, which is usually a
> clue it's probably the wrong thing to do.
Depends, if it is not selected you'll end with wrongly configured system. 

> > +	select MTD_PARTITIONED_MASTER
> >  	help
> >  	  Choose this option if you have a system that has "Intel Graphics
> >  	  Media Accelerator" or "HD Graphics" integrated graphics, diff
> > --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 7fa9120feb8d..f209cd541eec 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -299,6 +299,9 @@ endif
> >  obj-$(CONFIG_DRM_I915) += i915.o
> >  obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
> >
> > +obj-m += i915_spi.o
> 
> And literally nobody does this.
> 
> > +i915_spi-y := spi/intel_spi_drv.o
> 
> Time to add a separate Kconfig and Makefile in spi/?
Can be done. 
> 
> BR,
> Jani.
> 
> > +
> >  # header test
> >
> >  # exclude some broken headers from the test coverage diff --git
> > a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
> > b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
> > new file mode 100644
> > index 000000000000..23261f35b71f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
> > @@ -0,0 +1,116 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> > + */
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/kernel.h>
> > +#include <linux/string.h>
> > +#include <linux/io.h>
> > +#include <linux/device.h>
> > +#include <linux/slab.h>
> > +#include <linux/platform_device.h>
> > +#include <spi/intel_spi.h>
> 
> Should this have "" instead of <>?
> 
> > +
> > +struct i915_spi {
> > +	void __iomem *base;
> > +	size_t size;
> > +	unsigned int nregions;
> > +	struct {
> > +		const char *name;
> > +		u8 id;
> > +		u64 offset;
> > +		u64 size;
> > +	} regions[];
> > +};
> > +
> > +static int i915_spi_probe(struct platform_device *platdev) {
> > +	struct resource *bar;
> > +	struct device *device;
> > +	struct i915_spi *spi;
> > +	struct i915_spi_region *regions;
> > +	unsigned int nregions;
> > +	unsigned int i, n;
> > +	size_t size;
> > +	char *name;
> > +	size_t name_size;
> > +
> > +	device = &platdev->dev;
> > +
> > +	regions = dev_get_platdata(&platdev->dev);
> > +	if (!regions) {
> > +		dev_err(device, "no regions defined\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	/* count available regions */
> > +	for (nregions = 0, i = 0; i < I915_SPI_REGIONS; i++) {
> > +		if (regions[i].name)
> > +			nregions++;
> > +	}
> > +
> > +	if (!nregions) {
> > +		dev_err(device, "no regions defined\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	size = sizeof(*spi) + sizeof(spi->regions[0]) * nregions;
> > +	spi = devm_kzalloc(device, size, GFP_KERNEL);
> > +	if (!spi)
> > +		return -ENOMEM;
> > +
> > +	spi->nregions = nregions;
> > +	for (n = 0, i = 0; i < I915_SPI_REGIONS; i++) {
> > +		if (regions[i].name) {
> > +			name_size = strlen(dev_name(&platdev->dev)) +
> > +				    strlen(regions[i].name) + 2; /* for point */
> > +			name = devm_kzalloc(device, name_size,
> GFP_KERNEL);
> > +			if (!name)
> > +				continue;
> > +			snprintf(name, name_size, "%s.%s",
> > +				 dev_name(&platdev->dev),
> regions[i].name);
> > +			spi->regions[n].name = name;
> > +			spi->regions[n].id = i;
> > +			n++;
> > +		}
> > +	}
> > +
> > +	bar = platform_get_resource(platdev, IORESOURCE_MEM, 0);
> > +	if (!bar)
> > +		return -ENODEV;
> > +
> > +	spi->base = devm_ioremap_resource(device, bar);
> > +	if (IS_ERR(spi->base)) {
> > +		dev_err(device, "mmio not mapped\n");
> > +		return PTR_ERR(spi->base);
> > +	}
> > +
> > +	platform_set_drvdata(platdev, spi);
> > +
> > +	dev_dbg(device, "i915-spi is bound\n");
> > +
> > +	return 0;
> > +}
> > +
> > +static int i915_spi_remove(struct platform_device *platdev) {
> > +	platform_set_drvdata(platdev, NULL);
> > +
> > +	return 0;
> > +}
> > +
> > +MODULE_ALIAS("platform:i915-spi");
> > +static struct platform_driver i915_spi_driver = {
> > +	.probe  = i915_spi_probe,
> > +	.remove = i915_spi_remove,
> > +	.driver = {
> > +		.name = "i915-spi",
> > +	},
> > +};
> > +
> > +module_platform_driver(i915_spi_driver);
> > +
> > +MODULE_LICENSE("GPL and additional rights"); MODULE_AUTHOR("Intel
> > +Corporation"); MODULE_DESCRIPTION("Intel DGFX SPI driver");
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Winkler, Tomas]

> 
> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> > Add the platform driver for i915 on-die spi device, exposed via mfd
> > framework.
> >
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > ---
> >  drivers/gpu/drm/i915/Kconfig             |   2 +
> >  drivers/gpu/drm/i915/Makefile            |   3 +
> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
> > +++++++++++++++++++++++
> >  3 files changed, 121 insertions(+)
> >  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c
> >
> > diff --git a/drivers/gpu/drm/i915/Kconfig
> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e 100644
> > --- a/drivers/gpu/drm/i915/Kconfig
> > +++ b/drivers/gpu/drm/i915/Kconfig
> > @@ -27,6 +27,8 @@ config DRM_I915
> >  	select CEC_CORE if CEC_NOTIFIER
> >  	select VMAP_PFN
> >  	select MFD_CORE
> > +	select MTD
> 
> Selecting MTD does not seem to be a popular thing to do, which is usually a
> clue it's probably the wrong thing to do.
Depends, if it is not selected you'll end with wrongly configured system. 

> > +	select MTD_PARTITIONED_MASTER
> >  	help
> >  	  Choose this option if you have a system that has "Intel Graphics
> >  	  Media Accelerator" or "HD Graphics" integrated graphics, diff
> > --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 7fa9120feb8d..f209cd541eec 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -299,6 +299,9 @@ endif
> >  obj-$(CONFIG_DRM_I915) += i915.o
> >  obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
> >
> > +obj-m += i915_spi.o
> 
> And literally nobody does this.
> 
> > +i915_spi-y := spi/intel_spi_drv.o
> 
> Time to add a separate Kconfig and Makefile in spi/?
Can be done. 
> 
> BR,
> Jani.
> 
> > +
> >  # header test
> >
> >  # exclude some broken headers from the test coverage diff --git
> > a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
> > b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
> > new file mode 100644
> > index 000000000000..23261f35b71f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
> > @@ -0,0 +1,116 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright(c) 2019-2021, Intel Corporation. All rights reserved.
> > + */
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/kernel.h>
> > +#include <linux/string.h>
> > +#include <linux/io.h>
> > +#include <linux/device.h>
> > +#include <linux/slab.h>
> > +#include <linux/platform_device.h>
> > +#include <spi/intel_spi.h>
> 
> Should this have "" instead of <>?
> 
> > +
> > +struct i915_spi {
> > +	void __iomem *base;
> > +	size_t size;
> > +	unsigned int nregions;
> > +	struct {
> > +		const char *name;
> > +		u8 id;
> > +		u64 offset;
> > +		u64 size;
> > +	} regions[];
> > +};
> > +
> > +static int i915_spi_probe(struct platform_device *platdev) {
> > +	struct resource *bar;
> > +	struct device *device;
> > +	struct i915_spi *spi;
> > +	struct i915_spi_region *regions;
> > +	unsigned int nregions;
> > +	unsigned int i, n;
> > +	size_t size;
> > +	char *name;
> > +	size_t name_size;
> > +
> > +	device = &platdev->dev;
> > +
> > +	regions = dev_get_platdata(&platdev->dev);
> > +	if (!regions) {
> > +		dev_err(device, "no regions defined\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	/* count available regions */
> > +	for (nregions = 0, i = 0; i < I915_SPI_REGIONS; i++) {
> > +		if (regions[i].name)
> > +			nregions++;
> > +	}
> > +
> > +	if (!nregions) {
> > +		dev_err(device, "no regions defined\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	size = sizeof(*spi) + sizeof(spi->regions[0]) * nregions;
> > +	spi = devm_kzalloc(device, size, GFP_KERNEL);
> > +	if (!spi)
> > +		return -ENOMEM;
> > +
> > +	spi->nregions = nregions;
> > +	for (n = 0, i = 0; i < I915_SPI_REGIONS; i++) {
> > +		if (regions[i].name) {
> > +			name_size = strlen(dev_name(&platdev->dev)) +
> > +				    strlen(regions[i].name) + 2; /* for point */
> > +			name = devm_kzalloc(device, name_size,
> GFP_KERNEL);
> > +			if (!name)
> > +				continue;
> > +			snprintf(name, name_size, "%s.%s",
> > +				 dev_name(&platdev->dev),
> regions[i].name);
> > +			spi->regions[n].name = name;
> > +			spi->regions[n].id = i;
> > +			n++;
> > +		}
> > +	}
> > +
> > +	bar = platform_get_resource(platdev, IORESOURCE_MEM, 0);
> > +	if (!bar)
> > +		return -ENODEV;
> > +
> > +	spi->base = devm_ioremap_resource(device, bar);
> > +	if (IS_ERR(spi->base)) {
> > +		dev_err(device, "mmio not mapped\n");
> > +		return PTR_ERR(spi->base);
> > +	}
> > +
> > +	platform_set_drvdata(platdev, spi);
> > +
> > +	dev_dbg(device, "i915-spi is bound\n");
> > +
> > +	return 0;
> > +}
> > +
> > +static int i915_spi_remove(struct platform_device *platdev) {
> > +	platform_set_drvdata(platdev, NULL);
> > +
> > +	return 0;
> > +}
> > +
> > +MODULE_ALIAS("platform:i915-spi");
> > +static struct platform_driver i915_spi_driver = {
> > +	.probe  = i915_spi_probe,
> > +	.remove = i915_spi_remove,
> > +	.driver = {
> > +		.name = "i915-spi",
> > +	},
> > +};
> > +
> > +module_platform_driver(i915_spi_driver);
> > +
> > +MODULE_LICENSE("GPL and additional rights"); MODULE_AUTHOR("Intel
> > +Corporation"); MODULE_DESCRIPTION("Intel DGFX SPI driver");
> 
> --
> Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Lucas De Marchi]

On Wed, Feb 17, 2021 at 08:58:12PM +0000, Winkler, Tomas wrote:
>>
>> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> > Add the platform driver for i915 on-die spi device, exposed via mfd
>> > framework.
>> >
>> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/Kconfig             |   2 +
>> >  drivers/gpu/drm/i915/Makefile            |   3 +
>> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
>> > +++++++++++++++++++++++
>> >  3 files changed, 121 insertions(+)
>> >  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c
>> >
>> > diff --git a/drivers/gpu/drm/i915/Kconfig
>> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e 100644
>> > --- a/drivers/gpu/drm/i915/Kconfig
>> > +++ b/drivers/gpu/drm/i915/Kconfig
>> > @@ -27,6 +27,8 @@ config DRM_I915
>> >  	select CEC_CORE if CEC_NOTIFIER
>> >  	select VMAP_PFN
>> >  	select MFD_CORE
>> > +	select MTD
>>
>> Selecting MTD does not seem to be a popular thing to do, which is usually a
>> clue it's probably the wrong thing to do.
>Depends, if it is not selected you'll end with wrongly configured system.

no. I believe the idea is that having a CONFIG_I915_SPI, you could do

	depends on MTD

like the other drivers doing similar thing:

	git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig'

Lucas De Marchi

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Lucas De Marchi]

On Wed, Feb 17, 2021 at 08:58:12PM +0000, Winkler, Tomas wrote:
>>
>> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> > Add the platform driver for i915 on-die spi device, exposed via mfd
>> > framework.
>> >
>> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/Kconfig             |   2 +
>> >  drivers/gpu/drm/i915/Makefile            |   3 +
>> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
>> > +++++++++++++++++++++++
>> >  3 files changed, 121 insertions(+)
>> >  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c
>> >
>> > diff --git a/drivers/gpu/drm/i915/Kconfig
>> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e 100644
>> > --- a/drivers/gpu/drm/i915/Kconfig
>> > +++ b/drivers/gpu/drm/i915/Kconfig
>> > @@ -27,6 +27,8 @@ config DRM_I915
>> >  	select CEC_CORE if CEC_NOTIFIER
>> >  	select VMAP_PFN
>> >  	select MFD_CORE
>> > +	select MTD
>>
>> Selecting MTD does not seem to be a popular thing to do, which is usually a
>> clue it's probably the wrong thing to do.
>Depends, if it is not selected you'll end with wrongly configured system.

no. I believe the idea is that having a CONFIG_I915_SPI, you could do

	depends on MTD

like the other drivers doing similar thing:

	git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig'

Lucas De Marchi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Winkler, Tomas]

> 
> On Wed, Feb 17, 2021 at 08:58:12PM +0000, Winkler, Tomas wrote:
> >>
> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> >> > Add the platform driver for i915 on-die spi device, exposed via mfd
> >> > framework.
> >> >
> >> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> >> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> >> > ---
> >> >  drivers/gpu/drm/i915/Kconfig             |   2 +
> >> >  drivers/gpu/drm/i915/Makefile            |   3 +
> >> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
> >> > +++++++++++++++++++++++
> >> >  3 files changed, 121 insertions(+)  create mode 100644
> >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/Kconfig
> >> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e
> >> > 100644
> >> > --- a/drivers/gpu/drm/i915/Kconfig
> >> > +++ b/drivers/gpu/drm/i915/Kconfig
> >> > @@ -27,6 +27,8 @@ config DRM_I915
> >> >  	select CEC_CORE if CEC_NOTIFIER
> >> >  	select VMAP_PFN
> >> >  	select MFD_CORE
> >> > +	select MTD
> >>
> >> Selecting MTD does not seem to be a popular thing to do, which is
> >> usually a clue it's probably the wrong thing to do.
> >Depends, if it is not selected you'll end with wrongly configured system.
> 
> no. I believe the idea is that having a CONFIG_I915_SPI, you could do
> 
> 	depends on MTD
> 
> like the other drivers doing similar thing:
> 
> 	git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig'
MTD is usually used on embedded systems rather than on general distros, i915_spi and actually a bit redefines its usage 
so w/o forceful select, it won't be enabled.

> 
> Lucas De Marchi

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Winkler, Tomas]

> 
> On Wed, Feb 17, 2021 at 08:58:12PM +0000, Winkler, Tomas wrote:
> >>
> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> >> > Add the platform driver for i915 on-die spi device, exposed via mfd
> >> > framework.
> >> >
> >> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> >> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> >> > ---
> >> >  drivers/gpu/drm/i915/Kconfig             |   2 +
> >> >  drivers/gpu/drm/i915/Makefile            |   3 +
> >> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
> >> > +++++++++++++++++++++++
> >> >  3 files changed, 121 insertions(+)  create mode 100644
> >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/Kconfig
> >> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e
> >> > 100644
> >> > --- a/drivers/gpu/drm/i915/Kconfig
> >> > +++ b/drivers/gpu/drm/i915/Kconfig
> >> > @@ -27,6 +27,8 @@ config DRM_I915
> >> >  	select CEC_CORE if CEC_NOTIFIER
> >> >  	select VMAP_PFN
> >> >  	select MFD_CORE
> >> > +	select MTD
> >>
> >> Selecting MTD does not seem to be a popular thing to do, which is
> >> usually a clue it's probably the wrong thing to do.
> >Depends, if it is not selected you'll end with wrongly configured system.
> 
> no. I believe the idea is that having a CONFIG_I915_SPI, you could do
> 
> 	depends on MTD
> 
> like the other drivers doing similar thing:
> 
> 	git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig'
MTD is usually used on embedded systems rather than on general distros, i915_spi and actually a bit redefines its usage 
so w/o forceful select, it won't be enabled.

> 
> Lucas De Marchi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Winkler, Tomas]

> 
> On Wed, Feb 17, 2021 at 08:58:12PM +0000, Winkler, Tomas wrote:
> >>
> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> >> > Add the platform driver for i915 on-die spi device, exposed via mfd
> >> > framework.
> >> >
> >> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> >> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> >> > ---
> >> >  drivers/gpu/drm/i915/Kconfig             |   2 +
> >> >  drivers/gpu/drm/i915/Makefile            |   3 +
> >> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
> >> > +++++++++++++++++++++++
> >> >  3 files changed, 121 insertions(+)  create mode 100644
> >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/Kconfig
> >> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e
> >> > 100644
> >> > --- a/drivers/gpu/drm/i915/Kconfig
> >> > +++ b/drivers/gpu/drm/i915/Kconfig
> >> > @@ -27,6 +27,8 @@ config DRM_I915
> >> >  	select CEC_CORE if CEC_NOTIFIER
> >> >  	select VMAP_PFN
> >> >  	select MFD_CORE
> >> > +	select MTD
> >>
> >> Selecting MTD does not seem to be a popular thing to do, which is
> >> usually a clue it's probably the wrong thing to do.
> >Depends, if it is not selected you'll end with wrongly configured system.
> 
> no. I believe the idea is that having a CONFIG_I915_SPI, you could do
> 
> 	depends on MTD
> 
> like the other drivers doing similar thing:
> 
> 	git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig'
 I know the pattern and it can be done, the issue is that mtd is used mostly in embedded systems so it is not selected by the desktop distros.
The intel spi both on PCH and in GFX takes this into different direction and usage.

Thanks
Tomas


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Winkler, Tomas]

> 
> On Wed, Feb 17, 2021 at 08:58:12PM +0000, Winkler, Tomas wrote:
> >>
> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> >> > Add the platform driver for i915 on-die spi device, exposed via mfd
> >> > framework.
> >> >
> >> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> >> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> >> > ---
> >> >  drivers/gpu/drm/i915/Kconfig             |   2 +
> >> >  drivers/gpu/drm/i915/Makefile            |   3 +
> >> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
> >> > +++++++++++++++++++++++
> >> >  3 files changed, 121 insertions(+)  create mode 100644
> >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/Kconfig
> >> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e
> >> > 100644
> >> > --- a/drivers/gpu/drm/i915/Kconfig
> >> > +++ b/drivers/gpu/drm/i915/Kconfig
> >> > @@ -27,6 +27,8 @@ config DRM_I915
> >> >  	select CEC_CORE if CEC_NOTIFIER
> >> >  	select VMAP_PFN
> >> >  	select MFD_CORE
> >> > +	select MTD
> >>
> >> Selecting MTD does not seem to be a popular thing to do, which is
> >> usually a clue it's probably the wrong thing to do.
> >Depends, if it is not selected you'll end with wrongly configured system.
> 
> no. I believe the idea is that having a CONFIG_I915_SPI, you could do
> 
> 	depends on MTD
> 
> like the other drivers doing similar thing:
> 
> 	git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig'
 I know the pattern and it can be done, the issue is that mtd is used mostly in embedded systems so it is not selected by the desktop distros.
The intel spi both on PCH and in GFX takes this into different direction and usage.

Thanks
Tomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Lucas De Marchi]

On Thu, Feb 18, 2021 at 10:06:08PM -0800, Winkler, Tomas wrote:
>
>>
>> On Wed, Feb 17, 2021 at 08:58:12PM +0000, Winkler, Tomas wrote:
>> >>
>> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> >> > Add the platform driver for i915 on-die spi device, exposed via mfd
>> >> > framework.
>> >> >
>> >> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> >> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> >> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>> >> > ---
>> >> >  drivers/gpu/drm/i915/Kconfig             |   2 +
>> >> >  drivers/gpu/drm/i915/Makefile            |   3 +
>> >> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
>> >> > +++++++++++++++++++++++
>> >> >  3 files changed, 121 insertions(+)  create mode 100644
>> >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/Kconfig
>> >> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e
>> >> > 100644
>> >> > --- a/drivers/gpu/drm/i915/Kconfig
>> >> > +++ b/drivers/gpu/drm/i915/Kconfig
>> >> > @@ -27,6 +27,8 @@ config DRM_I915
>> >> >  	select CEC_CORE if CEC_NOTIFIER
>> >> >  	select VMAP_PFN
>> >> >  	select MFD_CORE
>> >> > +	select MTD
>> >>
>> >> Selecting MTD does not seem to be a popular thing to do, which is
>> >> usually a clue it's probably the wrong thing to do.
>> >Depends, if it is not selected you'll end with wrongly configured system.
>>
>> no. I believe the idea is that having a CONFIG_I915_SPI, you could do
>>
>> 	depends on MTD
>>
>> like the other drivers doing similar thing:
>>
>> 	git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig'
> I know the pattern and it can be done, the issue is that mtd is used mostly in embedded systems so it is not selected by the desktop distros.
>The intel spi both on PCH and in GFX takes this into different direction and usage.

humn... but then we have a problem here. You're saying most of the
people won't need it because it's used only for manufacturing*.
And yet you want it to be force selected on everybody?  That
doesn't sound like a good plan.

Lucas De Marchi


* it may actually also be useful for kernel developers too, to dump its
content and validate the parser, help debug other systems, etc.

>
>Thanks
>Tomas
>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Lucas De Marchi]

On Thu, Feb 18, 2021 at 10:06:08PM -0800, Winkler, Tomas wrote:
>
>>
>> On Wed, Feb 17, 2021 at 08:58:12PM +0000, Winkler, Tomas wrote:
>> >>
>> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> >> > Add the platform driver for i915 on-die spi device, exposed via mfd
>> >> > framework.
>> >> >
>> >> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> >> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> >> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>> >> > ---
>> >> >  drivers/gpu/drm/i915/Kconfig             |   2 +
>> >> >  drivers/gpu/drm/i915/Makefile            |   3 +
>> >> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
>> >> > +++++++++++++++++++++++
>> >> >  3 files changed, 121 insertions(+)  create mode 100644
>> >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/Kconfig
>> >> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e
>> >> > 100644
>> >> > --- a/drivers/gpu/drm/i915/Kconfig
>> >> > +++ b/drivers/gpu/drm/i915/Kconfig
>> >> > @@ -27,6 +27,8 @@ config DRM_I915
>> >> >  	select CEC_CORE if CEC_NOTIFIER
>> >> >  	select VMAP_PFN
>> >> >  	select MFD_CORE
>> >> > +	select MTD
>> >>
>> >> Selecting MTD does not seem to be a popular thing to do, which is
>> >> usually a clue it's probably the wrong thing to do.
>> >Depends, if it is not selected you'll end with wrongly configured system.
>>
>> no. I believe the idea is that having a CONFIG_I915_SPI, you could do
>>
>> 	depends on MTD
>>
>> like the other drivers doing similar thing:
>>
>> 	git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig'
> I know the pattern and it can be done, the issue is that mtd is used mostly in embedded systems so it is not selected by the desktop distros.
>The intel spi both on PCH and in GFX takes this into different direction and usage.

humn... but then we have a problem here. You're saying most of the
people won't need it because it's used only for manufacturing*.
And yet you want it to be force selected on everybody?  That
doesn't sound like a good plan.

Lucas De Marchi


* it may actually also be useful for kernel developers too, to dump its
content and validate the parser, help debug other systems, etc.

>
>Thanks
>Tomas
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Winkler, Tomas]

> On Thu, Feb 18, 2021 at 10:06:08PM -0800, Winkler, Tomas wrote:
> >
> >>
> >> On Wed, Feb 17, 2021 at 08:58:12PM +0000, Winkler, Tomas wrote:
> >> >>
> >> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com>
> wrote:
> >> >> > Add the platform driver for i915 on-die spi device, exposed via
> >> >> > mfd framework.
> >> >> >
> >> >> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >> >> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> >> >> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> >> >> > ---
> >> >> >  drivers/gpu/drm/i915/Kconfig             |   2 +
> >> >> >  drivers/gpu/drm/i915/Makefile            |   3 +
> >> >> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
> >> >> > +++++++++++++++++++++++
> >> >> >  3 files changed, 121 insertions(+)  create mode 100644
> >> >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/i915/Kconfig
> >> >> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e
> >> >> > 100644
> >> >> > --- a/drivers/gpu/drm/i915/Kconfig
> >> >> > +++ b/drivers/gpu/drm/i915/Kconfig
> >> >> > @@ -27,6 +27,8 @@ config DRM_I915
> >> >> >  	select CEC_CORE if CEC_NOTIFIER
> >> >> >  	select VMAP_PFN
> >> >> >  	select MFD_CORE
> >> >> > +	select MTD
> >> >>
> >> >> Selecting MTD does not seem to be a popular thing to do, which is
> >> >> usually a clue it's probably the wrong thing to do.
> >> >Depends, if it is not selected you'll end with wrongly configured system.
> >>
> >> no. I believe the idea is that having a CONFIG_I915_SPI, you could do
> >>
> >> 	depends on MTD
> >>
> >> like the other drivers doing similar thing:
> >>
> >> 	git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig'
> > I know the pattern and it can be done, the issue is that mtd is used mostly
> in embedded systems so it is not selected by the desktop distros.
> >The intel spi both on PCH and in GFX takes this into different direction and
> usage.
> 
> humn... but then we have a problem here. You're saying most of the people
> won't need it because it's used only for manufacturing*.
> And yet you want it to be force selected on everybody?  That doesn't sound
> like a good plan.
It depends, whether manufacturing is done on shipping OS or not, both approaches are in use.
One approach for the first case can be that the distro prevent the module loading via modprobe.d 
and it's forcefully loaded during manufacturing.  Still it should be compiled and signed.
> 
> Lucas De Marchi
> 
> 
> * it may actually also be useful for kernel developers too, to dump its content
> and validate the parser, help debug other systems, etc.
True.


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

[Winkler, Tomas]

> On Thu, Feb 18, 2021 at 10:06:08PM -0800, Winkler, Tomas wrote:
> >
> >>
> >> On Wed, Feb 17, 2021 at 08:58:12PM +0000, Winkler, Tomas wrote:
> >> >>
> >> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com>
> wrote:
> >> >> > Add the platform driver for i915 on-die spi device, exposed via
> >> >> > mfd framework.
> >> >> >
> >> >> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >> >> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> >> >> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> >> >> > ---
> >> >> >  drivers/gpu/drm/i915/Kconfig             |   2 +
> >> >> >  drivers/gpu/drm/i915/Makefile            |   3 +
> >> >> >  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116
> >> >> > +++++++++++++++++++++++
> >> >> >  3 files changed, 121 insertions(+)  create mode 100644
> >> >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/i915/Kconfig
> >> >> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e
> >> >> > 100644
> >> >> > --- a/drivers/gpu/drm/i915/Kconfig
> >> >> > +++ b/drivers/gpu/drm/i915/Kconfig
> >> >> > @@ -27,6 +27,8 @@ config DRM_I915
> >> >> >  	select CEC_CORE if CEC_NOTIFIER
> >> >> >  	select VMAP_PFN
> >> >> >  	select MFD_CORE
> >> >> > +	select MTD
> >> >>
> >> >> Selecting MTD does not seem to be a popular thing to do, which is
> >> >> usually a clue it's probably the wrong thing to do.
> >> >Depends, if it is not selected you'll end with wrongly configured system.
> >>
> >> no. I believe the idea is that having a CONFIG_I915_SPI, you could do
> >>
> >> 	depends on MTD
> >>
> >> like the other drivers doing similar thing:
> >>
> >> 	git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig'
> > I know the pattern and it can be done, the issue is that mtd is used mostly
> in embedded systems so it is not selected by the desktop distros.
> >The intel spi both on PCH and in GFX takes this into different direction and
> usage.
> 
> humn... but then we have a problem here. You're saying most of the people
> won't need it because it's used only for manufacturing*.
> And yet you want it to be force selected on everybody?  That doesn't sound
> like a good plan.
It depends, whether manufacturing is done on shipping OS or not, both approaches are in use.
One approach for the first case can be that the distro prevent the module loading via modprobe.d 
and it's forcefully loaded during manufacturing.  Still it should be compiled and signed.
> 
> Lucas De Marchi
> 
> 
> * it may actually also be useful for kernel developers too, to dump its content
> and validate the parser, help debug other systems, etc.
True.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFC PATCH 4/9] drm/i915/spi: implement region enumeration

[Tomas Winkler]

In i915-spi, there is no access to the spi controller,
all the information has to be extracted form the descriptor region.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 190 +++++++++++++++++++++++
 1 file changed, 190 insertions(+)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
index 23261f35b71f..a1e7171d05db 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -16,14 +16,197 @@ struct i915_spi {
 	void __iomem *base;
 	size_t size;
 	unsigned int nregions;
+	u32 access_map;
 	struct {
 		const char *name;
 		u8 id;
 		u64 offset;
 		u64 size;
+		unsigned int is_readable:1;
+		unsigned int is_writable:1;
 	} regions[];
 };
 
+#define SPI_TRIGGER_REG       0x00000000
+#define SPI_VALSIG_REG        0x00000010
+#define SPI_ADDRESS_REG       0x00000040
+#define SPI_REGION_ID_REG     0x00000044
+/*
+ * [15:0]-Erase size = 0x0010 4K 0x0080 32K 0x0100 64K
+ * [23:16]-Reserved
+ * [31:24]-Erase SPI RegionID
+ */
+#define SPI_ERASE_REG         0x00000048
+#define SPI_ACCESS_ERROR_REG  0x00000070
+#define SPI_ADDRESS_ERROR_REG 0x00000074
+
+/* Flash Valid Signature */
+#define SPI_FLVALSIG          0x0FF0A55A
+
+#define SPI_MAP_ADDR_MASK     0x000000FF
+#define SPI_MAP_ADDR_SHIFT    0x00000004
+
+#define REGION_ID_DESCRIPTOR  0
+/* Flash Region Base Address */
+#define FRBA      0x40
+/* Flash Region __n - Flash Descriptor Record */
+#define FLREG(__n)  (FRBA + ((__n) * 4))
+/*  Flash Map 1 Register */
+#define FLMAP1_REG  0x18
+#define FLMSTR4_OFFSET 0x00C
+
+#define SPI_ACCESS_ERROR_PCIE_MASK 0x7
+
+static inline void spi_set_region_id(struct i915_spi *spi, u8 region)
+{
+	iowrite32((u32)region, spi->base + SPI_REGION_ID_REG);
+}
+
+static inline u32 spi_error(struct i915_spi *spi)
+{
+	u32 reg = ioread32(spi->base + SPI_ACCESS_ERROR_REG) &
+		  SPI_ACCESS_ERROR_PCIE_MASK;
+
+	/* reset error bits */
+	if (reg)
+		iowrite32(reg, spi->base + SPI_ACCESS_ERROR_REG);
+
+	return reg;
+}
+
+static inline u32 spi_read32(struct i915_spi *spi, u32 address)
+{
+	void __iomem *base = spi->base;
+
+	iowrite32(address, base + SPI_ADDRESS_REG);
+
+	return ioread32(base + SPI_TRIGGER_REG);
+}
+
+static int spi_get_access_map(struct i915_spi *spi)
+{
+	u32 flmap1;
+	u32 fmba;
+	u32 fmstr4;
+	u32 fmstr4_addr;
+
+	spi_set_region_id(spi, REGION_ID_DESCRIPTOR);
+
+	flmap1 = spi_read32(spi, FLMAP1_REG);
+	if (spi_error(spi))
+		return -EIO;
+	/* Get Flash Master Baser Address (FMBA) */
+	fmba = ((flmap1 & SPI_MAP_ADDR_MASK) << SPI_MAP_ADDR_SHIFT);
+	fmstr4_addr = fmba + FLMSTR4_OFFSET;
+
+	fmstr4 = spi_read32(spi, fmstr4_addr);
+	if (spi_error(spi))
+		return -EIO;
+
+	spi->access_map = fmstr4;
+	return 0;
+}
+
+static bool spi_region_readable(struct i915_spi *spi, u8 region)
+{
+	if (region < 12)
+		return spi->access_map & (1 << (region + 8)); /* [19:8] */
+	else
+		return spi->access_map & (1 << (region - 12)); /* [3:0] */
+}
+
+static bool spi_region_writeable(struct i915_spi *spi, u8 region)
+{
+	if (region < 12)
+		return spi->access_map & (1 << (region + 20)); /* [31:20] */
+	else
+		return spi->access_map & (1 << (region - 8)); /* [7:4] */
+}
+
+static int i915_spi_is_valid(struct i915_spi *spi)
+{
+	u32 is_valid;
+
+	spi_set_region_id(spi, REGION_ID_DESCRIPTOR);
+
+	is_valid = spi_read32(spi, SPI_VALSIG_REG);
+	if (spi_error(spi))
+		return -EIO;
+
+	if (is_valid != SPI_FLVALSIG)
+		return -ENODEV;
+
+	return 0;
+}
+
+static int i915_spi_init(struct i915_spi *spi, struct device *device)
+{
+	int ret;
+	unsigned int i, n;
+
+	/* clean error register, previous errors are ignored */
+	spi_error(spi);
+
+	ret = i915_spi_is_valid(spi);
+	if (ret) {
+		dev_err(device, "The SPI is not valid %d\n", ret);
+		return ret;
+	}
+
+	if (spi_get_access_map(spi))
+		return -EIO;
+
+	for (i = 0, n = 0; i < spi->nregions; i++) {
+		u32 address, base, limit, region;
+		u8 id = spi->regions[i].id;
+
+		address = FLREG(id);
+		region = spi_read32(spi, address);
+
+		base = (region & 0x0000FFFF) << 12;
+		limit = (((region & 0xFFFF0000) >> 16) << 12) | 0xFFF;
+
+		dev_dbg(device, "[%d] %s: region: 0x%08X base: 0x%08x limit: 0x%08x\n",
+			id, spi->regions[i].name, region, base, limit);
+
+		if (base >= limit || (i > 0 && limit == 0)) {
+			dev_dbg(device, "[%d] %s: disabled\n",
+				id, spi->regions[i].name);
+			spi->regions[i].is_readable = 0;
+			continue;
+		}
+
+		if (spi->size < limit)
+			spi->size = limit;
+
+		spi->regions[i].offset = base;
+		spi->regions[i].size = limit - base + 1;
+		/* No write access to descriptor; mask it out*/
+		spi->regions[i].is_writable = spi_region_writeable(spi, id);
+
+		spi->regions[i].is_readable = spi_region_readable(spi, id);
+		dev_dbg(device, "Registered, %s id=%d offset=%lld size=%lld rd=%d wr=%d\n",
+			spi->regions[i].name,
+			spi->regions[i].id,
+			spi->regions[i].offset,
+			spi->regions[i].size,
+			spi->regions[i].is_readable,
+			spi->regions[i].is_writable);
+
+		if (spi->regions[i].is_readable)
+			n++;
+	}
+
+	dev_dbg(device, "Registered %d regions\n", n);
+
+	/* Need to add 1 to the amount of memory
+	 * so it is reported as an even block
+	 */
+	spi->size += 1;
+
+	return n;
+}
+
 static int i915_spi_probe(struct platform_device *platdev)
 {
 	struct resource *bar;
@@ -35,6 +218,7 @@ static int i915_spi_probe(struct platform_device *platdev)
 	size_t size;
 	char *name;
 	size_t name_size;
+	int ret;
 
 	device = &platdev->dev;
 
@@ -86,6 +270,12 @@ static int i915_spi_probe(struct platform_device *platdev)
 		return PTR_ERR(spi->base);
 	}
 
+	ret = i915_spi_init(spi, device);
+	if (ret < 0) {
+		dev_err(device, "cannot initialize spi\n");
+		return -ENODEV;
+	}
+
 	platform_set_drvdata(platdev, spi);
 
 	dev_dbg(device, "i915-spi is bound\n");
-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[Intel-gfx] [RFC PATCH 4/9] drm/i915/spi: implement region enumeration

[Tomas Winkler]

In i915-spi, there is no access to the spi controller,
all the information has to be extracted form the descriptor region.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 190 +++++++++++++++++++++++
 1 file changed, 190 insertions(+)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
index 23261f35b71f..a1e7171d05db 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -16,14 +16,197 @@ struct i915_spi {
 	void __iomem *base;
 	size_t size;
 	unsigned int nregions;
+	u32 access_map;
 	struct {
 		const char *name;
 		u8 id;
 		u64 offset;
 		u64 size;
+		unsigned int is_readable:1;
+		unsigned int is_writable:1;
 	} regions[];
 };
 
+#define SPI_TRIGGER_REG       0x00000000
+#define SPI_VALSIG_REG        0x00000010
+#define SPI_ADDRESS_REG       0x00000040
+#define SPI_REGION_ID_REG     0x00000044
+/*
+ * [15:0]-Erase size = 0x0010 4K 0x0080 32K 0x0100 64K
+ * [23:16]-Reserved
+ * [31:24]-Erase SPI RegionID
+ */
+#define SPI_ERASE_REG         0x00000048
+#define SPI_ACCESS_ERROR_REG  0x00000070
+#define SPI_ADDRESS_ERROR_REG 0x00000074
+
+/* Flash Valid Signature */
+#define SPI_FLVALSIG          0x0FF0A55A
+
+#define SPI_MAP_ADDR_MASK     0x000000FF
+#define SPI_MAP_ADDR_SHIFT    0x00000004
+
+#define REGION_ID_DESCRIPTOR  0
+/* Flash Region Base Address */
+#define FRBA      0x40
+/* Flash Region __n - Flash Descriptor Record */
+#define FLREG(__n)  (FRBA + ((__n) * 4))
+/*  Flash Map 1 Register */
+#define FLMAP1_REG  0x18
+#define FLMSTR4_OFFSET 0x00C
+
+#define SPI_ACCESS_ERROR_PCIE_MASK 0x7
+
+static inline void spi_set_region_id(struct i915_spi *spi, u8 region)
+{
+	iowrite32((u32)region, spi->base + SPI_REGION_ID_REG);
+}
+
+static inline u32 spi_error(struct i915_spi *spi)
+{
+	u32 reg = ioread32(spi->base + SPI_ACCESS_ERROR_REG) &
+		  SPI_ACCESS_ERROR_PCIE_MASK;
+
+	/* reset error bits */
+	if (reg)
+		iowrite32(reg, spi->base + SPI_ACCESS_ERROR_REG);
+
+	return reg;
+}
+
+static inline u32 spi_read32(struct i915_spi *spi, u32 address)
+{
+	void __iomem *base = spi->base;
+
+	iowrite32(address, base + SPI_ADDRESS_REG);
+
+	return ioread32(base + SPI_TRIGGER_REG);
+}
+
+static int spi_get_access_map(struct i915_spi *spi)
+{
+	u32 flmap1;
+	u32 fmba;
+	u32 fmstr4;
+	u32 fmstr4_addr;
+
+	spi_set_region_id(spi, REGION_ID_DESCRIPTOR);
+
+	flmap1 = spi_read32(spi, FLMAP1_REG);
+	if (spi_error(spi))
+		return -EIO;
+	/* Get Flash Master Baser Address (FMBA) */
+	fmba = ((flmap1 & SPI_MAP_ADDR_MASK) << SPI_MAP_ADDR_SHIFT);
+	fmstr4_addr = fmba + FLMSTR4_OFFSET;
+
+	fmstr4 = spi_read32(spi, fmstr4_addr);
+	if (spi_error(spi))
+		return -EIO;
+
+	spi->access_map = fmstr4;
+	return 0;
+}
+
+static bool spi_region_readable(struct i915_spi *spi, u8 region)
+{
+	if (region < 12)
+		return spi->access_map & (1 << (region + 8)); /* [19:8] */
+	else
+		return spi->access_map & (1 << (region - 12)); /* [3:0] */
+}
+
+static bool spi_region_writeable(struct i915_spi *spi, u8 region)
+{
+	if (region < 12)
+		return spi->access_map & (1 << (region + 20)); /* [31:20] */
+	else
+		return spi->access_map & (1 << (region - 8)); /* [7:4] */
+}
+
+static int i915_spi_is_valid(struct i915_spi *spi)
+{
+	u32 is_valid;
+
+	spi_set_region_id(spi, REGION_ID_DESCRIPTOR);
+
+	is_valid = spi_read32(spi, SPI_VALSIG_REG);
+	if (spi_error(spi))
+		return -EIO;
+
+	if (is_valid != SPI_FLVALSIG)
+		return -ENODEV;
+
+	return 0;
+}
+
+static int i915_spi_init(struct i915_spi *spi, struct device *device)
+{
+	int ret;
+	unsigned int i, n;
+
+	/* clean error register, previous errors are ignored */
+	spi_error(spi);
+
+	ret = i915_spi_is_valid(spi);
+	if (ret) {
+		dev_err(device, "The SPI is not valid %d\n", ret);
+		return ret;
+	}
+
+	if (spi_get_access_map(spi))
+		return -EIO;
+
+	for (i = 0, n = 0; i < spi->nregions; i++) {
+		u32 address, base, limit, region;
+		u8 id = spi->regions[i].id;
+
+		address = FLREG(id);
+		region = spi_read32(spi, address);
+
+		base = (region & 0x0000FFFF) << 12;
+		limit = (((region & 0xFFFF0000) >> 16) << 12) | 0xFFF;
+
+		dev_dbg(device, "[%d] %s: region: 0x%08X base: 0x%08x limit: 0x%08x\n",
+			id, spi->regions[i].name, region, base, limit);
+
+		if (base >= limit || (i > 0 && limit == 0)) {
+			dev_dbg(device, "[%d] %s: disabled\n",
+				id, spi->regions[i].name);
+			spi->regions[i].is_readable = 0;
+			continue;
+		}
+
+		if (spi->size < limit)
+			spi->size = limit;
+
+		spi->regions[i].offset = base;
+		spi->regions[i].size = limit - base + 1;
+		/* No write access to descriptor; mask it out*/
+		spi->regions[i].is_writable = spi_region_writeable(spi, id);
+
+		spi->regions[i].is_readable = spi_region_readable(spi, id);
+		dev_dbg(device, "Registered, %s id=%d offset=%lld size=%lld rd=%d wr=%d\n",
+			spi->regions[i].name,
+			spi->regions[i].id,
+			spi->regions[i].offset,
+			spi->regions[i].size,
+			spi->regions[i].is_readable,
+			spi->regions[i].is_writable);
+
+		if (spi->regions[i].is_readable)
+			n++;
+	}
+
+	dev_dbg(device, "Registered %d regions\n", n);
+
+	/* Need to add 1 to the amount of memory
+	 * so it is reported as an even block
+	 */
+	spi->size += 1;
+
+	return n;
+}
+
 static int i915_spi_probe(struct platform_device *platdev)
 {
 	struct resource *bar;
@@ -35,6 +218,7 @@ static int i915_spi_probe(struct platform_device *platdev)
 	size_t size;
 	char *name;
 	size_t name_size;
+	int ret;
 
 	device = &platdev->dev;
 
@@ -86,6 +270,12 @@ static int i915_spi_probe(struct platform_device *platdev)
 		return PTR_ERR(spi->base);
 	}
 
+	ret = i915_spi_init(spi, device);
+	if (ret < 0) {
+		dev_err(device, "cannot initialize spi\n");
+		return -ENODEV;
+	}
+
 	platform_set_drvdata(platdev, spi);
 
 	dev_dbg(device, "i915-spi is bound\n");
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFC PATCH 5/9] drm/i915/spi: implement spi access functions

[Tomas Winkler]

Implement spi_read() spi_erase() spi_write() functions.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 137 +++++++++++++++++++++++
 1 file changed, 137 insertions(+)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
index a1e7171d05db..df6a461d520d 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -9,7 +9,10 @@
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/slab.h>
+#include <linux/sizes.h>
+#include <linux/io-64-nonatomic-lo-hi.h>
 #include <linux/platform_device.h>
+#include <linux/delay.h>
 #include <spi/intel_spi.h>
 
 struct i915_spi {
@@ -83,6 +86,33 @@ static inline u32 spi_read32(struct i915_spi *spi, u32 address)
 	return ioread32(base + SPI_TRIGGER_REG);
 }
 
+static inline u64 spi_read64(struct i915_spi *spi, u32 address)
+{
+	void __iomem *base = spi->base;
+
+	iowrite32(address, base + SPI_ADDRESS_REG);
+
+	return readq(base + SPI_TRIGGER_REG);
+}
+
+static void spi_write32(struct i915_spi *spi, u32 address, u32 data)
+{
+	void __iomem *base = spi->base;
+
+	iowrite32(address, base + SPI_ADDRESS_REG);
+
+	iowrite32(data, base + SPI_TRIGGER_REG);
+}
+
+static void spi_write64(struct i915_spi *spi, u32 address, u64 data)
+{
+	void __iomem *base = spi->base;
+
+	iowrite32(address, base + SPI_ADDRESS_REG);
+
+	writeq(data, base + SPI_TRIGGER_REG);
+}
+
 static int spi_get_access_map(struct i915_spi *spi)
 {
 	u32 flmap1;
@@ -139,6 +169,113 @@ static int i915_spi_is_valid(struct i915_spi *spi)
 	return 0;
 }
 
+__maybe_unused
+static unsigned int spi_get_region(const struct i915_spi *spi, loff_t from)
+{
+	unsigned int i;
+
+	for (i = 0; i < spi->nregions; i++) {
+		if ((spi->regions[i].offset + spi->regions[i].size - 1) > from &&
+		    spi->regions[i].offset <= from &&
+		    spi->regions[i].size != 0)
+			break;
+	}
+
+	return i;
+}
+
+__maybe_unused
+static ssize_t spi_write(struct i915_spi *spi, u8 region,
+			 loff_t to, size_t len, const unsigned char *buf)
+{
+	size_t i;
+	size_t len8;
+
+	spi_set_region_id(spi, region);
+
+	len8 = ALIGN_DOWN(len, sizeof(u64));
+	for (i = 0; i < len8; i += sizeof(u64)) {
+		u64 data;
+
+		memcpy(&data, &buf[i], sizeof(u64));
+		spi_write64(spi, to + i, data);
+		if (spi_error(spi))
+			return -EIO;
+	}
+
+	if (len8 != len) { /* caller ensure that write size is at least u32 */
+		u32 data;
+
+		memcpy(&data, &buf[i], sizeof(u32));
+		spi_write32(spi, to + len8, data);
+		if (spi_error(spi))
+			return -EIO;
+	}
+
+	return len;
+}
+
+__maybe_unused
+static ssize_t spi_read(struct i915_spi *spi, u8 region,
+			loff_t from, size_t len, unsigned char *buf)
+{
+	size_t i;
+	size_t len8;
+	size_t len4;
+
+	spi_set_region_id(spi, region);
+
+	len8 = ALIGN_DOWN(len, sizeof(u64));
+	for (i = 0; i < len8; i += sizeof(u64)) {
+		u64 data = spi_read64(spi, from + i);
+
+		if (spi_error(spi))
+			return -EIO;
+
+		memcpy(&buf[i], &data, sizeof(data));
+	}
+
+	len4 = len - len8;
+	if (len4 >= sizeof(u32)) {
+		u32 data = spi_read32(spi, from + i);
+
+		if (spi_error(spi))
+			return -EIO;
+		memcpy(&buf[i], &data, sizeof(data));
+		i += sizeof(u32);
+		len4 -= sizeof(u32);
+	}
+
+	if (len4 > 0) {
+		u32 data = spi_read32(spi, from + i);
+
+		if (spi_error(spi))
+			return -EIO;
+		memcpy(&buf[i], &data, len4);
+	}
+
+	return len;
+}
+
+__maybe_unused
+static ssize_t
+spi_erase(struct i915_spi *spi, u8 region, loff_t from, u64 len, u64 *fail_addr)
+{
+	u64 i;
+	const u32 block = 0x10;
+	void __iomem *base = spi->base;
+
+	for (i = 0; i < len; i += SZ_4K) {
+		iowrite32(from + i, base + SPI_ADDRESS_REG);
+		iowrite32(region << 24 | block, base + SPI_ERASE_REG);
+		/* Since the writes are via sguint
+		 * we cannot do back to back erases.
+		 */
+		msleep(50);
+	}
+	return len;
+}
+
 static int i915_spi_init(struct i915_spi *spi, struct device *device)
 {
 	int ret;
-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[Intel-gfx] [RFC PATCH 5/9] drm/i915/spi: implement spi access functions

[Tomas Winkler]

Implement spi_read() spi_erase() spi_write() functions.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 137 +++++++++++++++++++++++
 1 file changed, 137 insertions(+)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
index a1e7171d05db..df6a461d520d 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -9,7 +9,10 @@
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/slab.h>
+#include <linux/sizes.h>
+#include <linux/io-64-nonatomic-lo-hi.h>
 #include <linux/platform_device.h>
+#include <linux/delay.h>
 #include <spi/intel_spi.h>
 
 struct i915_spi {
@@ -83,6 +86,33 @@ static inline u32 spi_read32(struct i915_spi *spi, u32 address)
 	return ioread32(base + SPI_TRIGGER_REG);
 }
 
+static inline u64 spi_read64(struct i915_spi *spi, u32 address)
+{
+	void __iomem *base = spi->base;
+
+	iowrite32(address, base + SPI_ADDRESS_REG);
+
+	return readq(base + SPI_TRIGGER_REG);
+}
+
+static void spi_write32(struct i915_spi *spi, u32 address, u32 data)
+{
+	void __iomem *base = spi->base;
+
+	iowrite32(address, base + SPI_ADDRESS_REG);
+
+	iowrite32(data, base + SPI_TRIGGER_REG);
+}
+
+static void spi_write64(struct i915_spi *spi, u32 address, u64 data)
+{
+	void __iomem *base = spi->base;
+
+	iowrite32(address, base + SPI_ADDRESS_REG);
+
+	writeq(data, base + SPI_TRIGGER_REG);
+}
+
 static int spi_get_access_map(struct i915_spi *spi)
 {
 	u32 flmap1;
@@ -139,6 +169,113 @@ static int i915_spi_is_valid(struct i915_spi *spi)
 	return 0;
 }
 
+__maybe_unused
+static unsigned int spi_get_region(const struct i915_spi *spi, loff_t from)
+{
+	unsigned int i;
+
+	for (i = 0; i < spi->nregions; i++) {
+		if ((spi->regions[i].offset + spi->regions[i].size - 1) > from &&
+		    spi->regions[i].offset <= from &&
+		    spi->regions[i].size != 0)
+			break;
+	}
+
+	return i;
+}
+
+__maybe_unused
+static ssize_t spi_write(struct i915_spi *spi, u8 region,
+			 loff_t to, size_t len, const unsigned char *buf)
+{
+	size_t i;
+	size_t len8;
+
+	spi_set_region_id(spi, region);
+
+	len8 = ALIGN_DOWN(len, sizeof(u64));
+	for (i = 0; i < len8; i += sizeof(u64)) {
+		u64 data;
+
+		memcpy(&data, &buf[i], sizeof(u64));
+		spi_write64(spi, to + i, data);
+		if (spi_error(spi))
+			return -EIO;
+	}
+
+	if (len8 != len) { /* caller ensure that write size is at least u32 */
+		u32 data;
+
+		memcpy(&data, &buf[i], sizeof(u32));
+		spi_write32(spi, to + len8, data);
+		if (spi_error(spi))
+			return -EIO;
+	}
+
+	return len;
+}
+
+__maybe_unused
+static ssize_t spi_read(struct i915_spi *spi, u8 region,
+			loff_t from, size_t len, unsigned char *buf)
+{
+	size_t i;
+	size_t len8;
+	size_t len4;
+
+	spi_set_region_id(spi, region);
+
+	len8 = ALIGN_DOWN(len, sizeof(u64));
+	for (i = 0; i < len8; i += sizeof(u64)) {
+		u64 data = spi_read64(spi, from + i);
+
+		if (spi_error(spi))
+			return -EIO;
+
+		memcpy(&buf[i], &data, sizeof(data));
+	}
+
+	len4 = len - len8;
+	if (len4 >= sizeof(u32)) {
+		u32 data = spi_read32(spi, from + i);
+
+		if (spi_error(spi))
+			return -EIO;
+		memcpy(&buf[i], &data, sizeof(data));
+		i += sizeof(u32);
+		len4 -= sizeof(u32);
+	}
+
+	if (len4 > 0) {
+		u32 data = spi_read32(spi, from + i);
+
+		if (spi_error(spi))
+			return -EIO;
+		memcpy(&buf[i], &data, len4);
+	}
+
+	return len;
+}
+
+__maybe_unused
+static ssize_t
+spi_erase(struct i915_spi *spi, u8 region, loff_t from, u64 len, u64 *fail_addr)
+{
+	u64 i;
+	const u32 block = 0x10;
+	void __iomem *base = spi->base;
+
+	for (i = 0; i < len; i += SZ_4K) {
+		iowrite32(from + i, base + SPI_ADDRESS_REG);
+		iowrite32(region << 24 | block, base + SPI_ERASE_REG);
+		/* Since the writes are via sguint
+		 * we cannot do back to back erases.
+		 */
+		msleep(50);
+	}
+	return len;
+}
+
 static int i915_spi_init(struct i915_spi *spi, struct device *device)
 {
 	int ret;
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFC PATCH 6/9] drm/i915/spi: spi register with mtd

[Tomas Winkler]

Register the on-die spi device with the mtd subsystem.
Add mtd access stub functions.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 86 +++++++++++++++++++++++-
 1 file changed, 85 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
index df6a461d520d..bdf58e14fd6b 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -15,7 +15,11 @@
 #include <linux/delay.h>
 #include <spi/intel_spi.h>
 
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+
 struct i915_spi {
+	struct mtd_info mtd;
 	void __iomem *base;
 	size_t size;
 	unsigned int nregions;
@@ -344,6 +348,73 @@ static int i915_spi_init(struct i915_spi *spi, struct device *device)
 	return n;
 }
 
+static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
+{
+	dev_err(&mtd->dev, "erasing %lld %lld\n", info->addr, info->len);
+
+	return 0;
+}
+
+static int i915_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
+			 size_t *retlen, u_char *buf)
+{
+	dev_err(&mtd->dev, "read %lld %zd\n", from, len);
+
+	return 0;
+}
+
+static int i915_spi_write(struct mtd_info *mtd, loff_t to, size_t len,
+			  size_t *retlen, const u_char *buf)
+{
+	dev_err(&mtd->dev, "writing %lld %zd\n", to, len);
+
+	return 0;
+}
+
+static int i915_spi_init_mtd(struct i915_spi *spi, struct device *device,
+			     unsigned int nparts)
+{
+	unsigned int i;
+	unsigned int n;
+	struct mtd_partition *parts = NULL;
+	int ret;
+
+	dev_dbg(device, "registering with mtd\n");
+
+	spi->mtd.owner = THIS_MODULE;
+	spi->mtd.dev.parent = device;
+	spi->mtd.flags = MTD_CAP_NORFLASH | MTD_WRITEABLE;
+	spi->mtd.type = MTD_DATAFLASH;
+	spi->mtd.priv = spi;
+	spi->mtd._write = i915_spi_write;
+	spi->mtd._read = i915_spi_read;
+	spi->mtd._erase = i915_spi_erase;
+	spi->mtd.writesize = SZ_4; /* 4 bytes granularity */
+	spi->mtd.erasesize = SZ_4K; /* 4K bytes granularity */
+	spi->mtd.size = spi->size;
+
+	parts = kcalloc(spi->nregions, sizeof(*parts), GFP_KERNEL);
+	if (!parts)
+		return -ENOMEM;
+
+	for (i = 0, n = 0; i < spi->nregions && n < nparts; i++) {
+		if (!spi->regions[i].is_readable)
+			continue;
+		parts[n].name = spi->regions[i].name;
+		parts[n].offset  = spi->regions[i].offset;
+		parts[n].size = spi->regions[i].size;
+		if (!spi->regions[i].is_writable)
+			parts[n].mask_flags = MTD_WRITEABLE;
+		n++;
+	}
+
+	ret = mtd_device_register(&spi->mtd, parts, n);
+
+	kfree(parts);
+
+	return ret;
+}
+
 static int i915_spi_probe(struct platform_device *platdev)
 {
 	struct resource *bar;
@@ -413,15 +484,28 @@ static int i915_spi_probe(struct platform_device *platdev)
 		return -ENODEV;
 	}
 
+	ret = i915_spi_init_mtd(spi, device, ret);
+	if (ret) {
+		dev_err(device, "i915-spi failed init mtd %d\n", ret);
+		return ret;
+	}
+
 	platform_set_drvdata(platdev, spi);
 
 	dev_dbg(device, "i915-spi is bound\n");
 
-	return 0;
+	return ret;
 }
 
 static int i915_spi_remove(struct platform_device *platdev)
 {
+	struct i915_spi *spi = platform_get_drvdata(platdev);
+
+	if (!spi)
+		return 0;
+
+	mtd_device_unregister(&spi->mtd);
+
 	platform_set_drvdata(platdev, NULL);
 
 	return 0;
-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[Intel-gfx] [RFC PATCH 6/9] drm/i915/spi: spi register with mtd

[Tomas Winkler]

Register the on-die spi device with the mtd subsystem.
Add mtd access stub functions.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 86 +++++++++++++++++++++++-
 1 file changed, 85 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
index df6a461d520d..bdf58e14fd6b 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -15,7 +15,11 @@
 #include <linux/delay.h>
 #include <spi/intel_spi.h>
 
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+
 struct i915_spi {
+	struct mtd_info mtd;
 	void __iomem *base;
 	size_t size;
 	unsigned int nregions;
@@ -344,6 +348,73 @@ static int i915_spi_init(struct i915_spi *spi, struct device *device)
 	return n;
 }
 
+static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
+{
+	dev_err(&mtd->dev, "erasing %lld %lld\n", info->addr, info->len);
+
+	return 0;
+}
+
+static int i915_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
+			 size_t *retlen, u_char *buf)
+{
+	dev_err(&mtd->dev, "read %lld %zd\n", from, len);
+
+	return 0;
+}
+
+static int i915_spi_write(struct mtd_info *mtd, loff_t to, size_t len,
+			  size_t *retlen, const u_char *buf)
+{
+	dev_err(&mtd->dev, "writing %lld %zd\n", to, len);
+
+	return 0;
+}
+
+static int i915_spi_init_mtd(struct i915_spi *spi, struct device *device,
+			     unsigned int nparts)
+{
+	unsigned int i;
+	unsigned int n;
+	struct mtd_partition *parts = NULL;
+	int ret;
+
+	dev_dbg(device, "registering with mtd\n");
+
+	spi->mtd.owner = THIS_MODULE;
+	spi->mtd.dev.parent = device;
+	spi->mtd.flags = MTD_CAP_NORFLASH | MTD_WRITEABLE;
+	spi->mtd.type = MTD_DATAFLASH;
+	spi->mtd.priv = spi;
+	spi->mtd._write = i915_spi_write;
+	spi->mtd._read = i915_spi_read;
+	spi->mtd._erase = i915_spi_erase;
+	spi->mtd.writesize = SZ_4; /* 4 bytes granularity */
+	spi->mtd.erasesize = SZ_4K; /* 4K bytes granularity */
+	spi->mtd.size = spi->size;
+
+	parts = kcalloc(spi->nregions, sizeof(*parts), GFP_KERNEL);
+	if (!parts)
+		return -ENOMEM;
+
+	for (i = 0, n = 0; i < spi->nregions && n < nparts; i++) {
+		if (!spi->regions[i].is_readable)
+			continue;
+		parts[n].name = spi->regions[i].name;
+		parts[n].offset  = spi->regions[i].offset;
+		parts[n].size = spi->regions[i].size;
+		if (!spi->regions[i].is_writable)
+			parts[n].mask_flags = MTD_WRITEABLE;
+		n++;
+	}
+
+	ret = mtd_device_register(&spi->mtd, parts, n);
+
+	kfree(parts);
+
+	return ret;
+}
+
 static int i915_spi_probe(struct platform_device *platdev)
 {
 	struct resource *bar;
@@ -413,15 +484,28 @@ static int i915_spi_probe(struct platform_device *platdev)
 		return -ENODEV;
 	}
 
+	ret = i915_spi_init_mtd(spi, device, ret);
+	if (ret) {
+		dev_err(device, "i915-spi failed init mtd %d\n", ret);
+		return ret;
+	}
+
 	platform_set_drvdata(platdev, spi);
 
 	dev_dbg(device, "i915-spi is bound\n");
 
-	return 0;
+	return ret;
 }
 
 static int i915_spi_remove(struct platform_device *platdev)
 {
+	struct i915_spi *spi = platform_get_drvdata(platdev);
+
+	if (!spi)
+		return 0;
+
+	mtd_device_unregister(&spi->mtd);
+
 	platform_set_drvdata(platdev, NULL);
 
 	return 0;
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFC PATCH 7/9] drm/i915/spi: mtd: implement access handlers

[Tomas Winkler]

Implement mtd read, erase, and write handlers.
For erase operation address and size should be 4K aligned.
For write operation address and size has to be 4bytes aligned.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 138 +++++++++++++++++++++--
 1 file changed, 131 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
index bdf58e14fd6b..1e8a40339e6d 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -173,7 +173,6 @@ static int i915_spi_is_valid(struct i915_spi *spi)
 	return 0;
 }
 
-__maybe_unused
 static unsigned int spi_get_region(const struct i915_spi *spi, loff_t from)
 {
 	unsigned int i;
@@ -188,7 +187,6 @@ static unsigned int spi_get_region(const struct i915_spi *spi, loff_t from)
 	return i;
 }
 
-__maybe_unused
 static ssize_t spi_write(struct i915_spi *spi, u8 region,
 			 loff_t to, size_t len, const unsigned char *buf)
 {
@@ -219,7 +217,6 @@ static ssize_t spi_write(struct i915_spi *spi, u8 region,
 	return len;
 }
 
-__maybe_unused
 static ssize_t spi_read(struct i915_spi *spi, u8 region,
 			loff_t from, size_t len, unsigned char *buf)
 {
@@ -261,7 +258,6 @@ static ssize_t spi_read(struct i915_spi *spi, u8 region,
 	return len;
 }
 
-__maybe_unused
 static ssize_t
 spi_erase(struct i915_spi *spi, u8 region, loff_t from, u64 len, u64 *fail_addr)
 {
@@ -350,7 +346,63 @@ static int i915_spi_init(struct i915_spi *spi, struct device *device)
 
 static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
 {
-	dev_err(&mtd->dev, "erasing %lld %lld\n", info->addr, info->len);
+	struct i915_spi *spi;
+	unsigned int idx;
+	u8 region;
+	u64 addr;
+	ssize_t bytes;
+	loff_t from;
+	size_t len;
+	size_t total_len;
+
+	if (!mtd || !info)
+		return -EINVAL;
+
+	spi = mtd->priv;
+
+	if (!IS_ALIGNED(info->addr, SZ_4K) || !IS_ALIGNED(info->len, SZ_4K)) {
+		dev_err(&mtd->dev, "unaligned erase %llx %llx\n",
+			info->addr, info->len);
+		info->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
+		return -EINVAL;
+	}
+
+	total_len = info->len;
+	addr = info->addr;
+
+	while (total_len > 0) {
+		if (!IS_ALIGNED(addr, SZ_4K) || !IS_ALIGNED(total_len, SZ_4K)) {
+			dev_err(&mtd->dev, "unaligned erase %llx %zx\n", addr, total_len);
+			info->fail_addr = addr;
+			return -ERANGE;
+		}
+
+		idx = spi_get_region(spi, addr);
+		if (idx >= spi->nregions) {
+			dev_err(&mtd->dev, "out of range");
+			info->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
+			return -ERANGE;
+		}
+
+		from = addr - spi->regions[idx].offset;
+		region = spi->regions[idx].id;
+		len = total_len;
+		if (len > spi->regions[idx].size - from)
+			len = spi->regions[idx].size - from;
+
+		dev_dbg(&mtd->dev, "erasing region[%d] %s from %llx len %zx\n",
+			region, spi->regions[idx].name, from, len);
+
+		bytes = spi_erase(spi, region, from, len, &info->fail_addr);
+		if (bytes < 0) {
+			dev_dbg(&mtd->dev, "erase failed with %zd\n", bytes);
+			info->fail_addr += spi->regions[idx].offset;
+			return bytes;
+		}
+
+		addr += len;
+		total_len -= len;
+	}
 
 	return 0;
 }
@@ -358,7 +410,43 @@ static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
 static int i915_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
 			 size_t *retlen, u_char *buf)
 {
-	dev_err(&mtd->dev, "read %lld %zd\n", from, len);
+	struct i915_spi *spi;
+	ssize_t ret;
+	unsigned int idx;
+	u8 region;
+
+	if (!mtd)
+		return -EINVAL;
+
+	spi = mtd->priv;
+
+	if (!IS_ALIGNED(from, sizeof(u32))) {
+		dev_err(&mtd->dev, "unaligned read %lld %zd\n", from, len);
+		return -EINVAL;
+	}
+
+	idx = spi_get_region(spi, from);
+
+	dev_dbg(&mtd->dev, "reading region[%d] %s from %lld len %zd\n",
+		spi->regions[idx].id, spi->regions[idx].name, from, len);
+
+	if (idx >= spi->nregions) {
+		dev_err(&mtd->dev, "out of ragnge");
+		return -ERANGE;
+	}
+
+	from -= spi->regions[idx].offset;
+	region = spi->regions[idx].id;
+	if (len > spi->regions[idx].size - from)
+		len = spi->regions[idx].size - from;
+
+	ret = spi_read(spi, region, from, len, buf);
+	if (ret < 0) {
+		dev_dbg(&mtd->dev, "read failed with %zd\n", ret);
+		return ret;
+	}
+
+	*retlen = ret;
 
 	return 0;
 }
@@ -366,7 +454,43 @@ static int i915_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
 static int i915_spi_write(struct mtd_info *mtd, loff_t to, size_t len,
 			  size_t *retlen, const u_char *buf)
 {
-	dev_err(&mtd->dev, "writing %lld %zd\n", to, len);
+	struct i915_spi *spi;
+	ssize_t ret;
+	unsigned int idx;
+	u8 region;
+
+	if (!mtd)
+		return -EINVAL;
+
+	spi = mtd->priv;
+
+	if (!(IS_ALIGNED(len, 4) && IS_ALIGNED(to, 4))) {
+		dev_err(&mtd->dev, "unaligned write %lld %zd\n", to, len);
+		return -EINVAL;
+	}
+
+	idx = spi_get_region(spi, to);
+
+	dev_dbg(&mtd->dev, "writing region[%d] %s to %lld len %zd\n",
+		spi->regions[idx].id, spi->regions[idx].name, to, len);
+
+	if (idx >= spi->nregions) {
+		dev_err(&mtd->dev, "out of range");
+		return -ERANGE;
+	}
+
+	to -= spi->regions[idx].offset;
+	region = spi->regions[idx].id;
+	if (len > spi->regions[idx].size - to)
+		len = spi->regions[idx].size - to;
+
+	ret = spi_write(spi, region, to, len, buf);
+	if (ret < 0) {
+		dev_dbg(&mtd->dev, "write failed with %zd\n", ret);
+		return ret;
+	}
+
+	*retlen = ret;
 
 	return 0;
 }
-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[Intel-gfx] [RFC PATCH 7/9] drm/i915/spi: mtd: implement access handlers

[Tomas Winkler]

Implement mtd read, erase, and write handlers.
For erase operation address and size should be 4K aligned.
For write operation address and size has to be 4bytes aligned.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 138 +++++++++++++++++++++--
 1 file changed, 131 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
index bdf58e14fd6b..1e8a40339e6d 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -173,7 +173,6 @@ static int i915_spi_is_valid(struct i915_spi *spi)
 	return 0;
 }
 
-__maybe_unused
 static unsigned int spi_get_region(const struct i915_spi *spi, loff_t from)
 {
 	unsigned int i;
@@ -188,7 +187,6 @@ static unsigned int spi_get_region(const struct i915_spi *spi, loff_t from)
 	return i;
 }
 
-__maybe_unused
 static ssize_t spi_write(struct i915_spi *spi, u8 region,
 			 loff_t to, size_t len, const unsigned char *buf)
 {
@@ -219,7 +217,6 @@ static ssize_t spi_write(struct i915_spi *spi, u8 region,
 	return len;
 }
 
-__maybe_unused
 static ssize_t spi_read(struct i915_spi *spi, u8 region,
 			loff_t from, size_t len, unsigned char *buf)
 {
@@ -261,7 +258,6 @@ static ssize_t spi_read(struct i915_spi *spi, u8 region,
 	return len;
 }
 
-__maybe_unused
 static ssize_t
 spi_erase(struct i915_spi *spi, u8 region, loff_t from, u64 len, u64 *fail_addr)
 {
@@ -350,7 +346,63 @@ static int i915_spi_init(struct i915_spi *spi, struct device *device)
 
 static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
 {
-	dev_err(&mtd->dev, "erasing %lld %lld\n", info->addr, info->len);
+	struct i915_spi *spi;
+	unsigned int idx;
+	u8 region;
+	u64 addr;
+	ssize_t bytes;
+	loff_t from;
+	size_t len;
+	size_t total_len;
+
+	if (!mtd || !info)
+		return -EINVAL;
+
+	spi = mtd->priv;
+
+	if (!IS_ALIGNED(info->addr, SZ_4K) || !IS_ALIGNED(info->len, SZ_4K)) {
+		dev_err(&mtd->dev, "unaligned erase %llx %llx\n",
+			info->addr, info->len);
+		info->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
+		return -EINVAL;
+	}
+
+	total_len = info->len;
+	addr = info->addr;
+
+	while (total_len > 0) {
+		if (!IS_ALIGNED(addr, SZ_4K) || !IS_ALIGNED(total_len, SZ_4K)) {
+			dev_err(&mtd->dev, "unaligned erase %llx %zx\n", addr, total_len);
+			info->fail_addr = addr;
+			return -ERANGE;
+		}
+
+		idx = spi_get_region(spi, addr);
+		if (idx >= spi->nregions) {
+			dev_err(&mtd->dev, "out of range");
+			info->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
+			return -ERANGE;
+		}
+
+		from = addr - spi->regions[idx].offset;
+		region = spi->regions[idx].id;
+		len = total_len;
+		if (len > spi->regions[idx].size - from)
+			len = spi->regions[idx].size - from;
+
+		dev_dbg(&mtd->dev, "erasing region[%d] %s from %llx len %zx\n",
+			region, spi->regions[idx].name, from, len);
+
+		bytes = spi_erase(spi, region, from, len, &info->fail_addr);
+		if (bytes < 0) {
+			dev_dbg(&mtd->dev, "erase failed with %zd\n", bytes);
+			info->fail_addr += spi->regions[idx].offset;
+			return bytes;
+		}
+
+		addr += len;
+		total_len -= len;
+	}
 
 	return 0;
 }
@@ -358,7 +410,43 @@ static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
 static int i915_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
 			 size_t *retlen, u_char *buf)
 {
-	dev_err(&mtd->dev, "read %lld %zd\n", from, len);
+	struct i915_spi *spi;
+	ssize_t ret;
+	unsigned int idx;
+	u8 region;
+
+	if (!mtd)
+		return -EINVAL;
+
+	spi = mtd->priv;
+
+	if (!IS_ALIGNED(from, sizeof(u32))) {
+		dev_err(&mtd->dev, "unaligned read %lld %zd\n", from, len);
+		return -EINVAL;
+	}
+
+	idx = spi_get_region(spi, from);
+
+	dev_dbg(&mtd->dev, "reading region[%d] %s from %lld len %zd\n",
+		spi->regions[idx].id, spi->regions[idx].name, from, len);
+
+	if (idx >= spi->nregions) {
+		dev_err(&mtd->dev, "out of ragnge");
+		return -ERANGE;
+	}
+
+	from -= spi->regions[idx].offset;
+	region = spi->regions[idx].id;
+	if (len > spi->regions[idx].size - from)
+		len = spi->regions[idx].size - from;
+
+	ret = spi_read(spi, region, from, len, buf);
+	if (ret < 0) {
+		dev_dbg(&mtd->dev, "read failed with %zd\n", ret);
+		return ret;
+	}
+
+	*retlen = ret;
 
 	return 0;
 }
@@ -366,7 +454,43 @@ static int i915_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
 static int i915_spi_write(struct mtd_info *mtd, loff_t to, size_t len,
 			  size_t *retlen, const u_char *buf)
 {
-	dev_err(&mtd->dev, "writing %lld %zd\n", to, len);
+	struct i915_spi *spi;
+	ssize_t ret;
+	unsigned int idx;
+	u8 region;
+
+	if (!mtd)
+		return -EINVAL;
+
+	spi = mtd->priv;
+
+	if (!(IS_ALIGNED(len, 4) && IS_ALIGNED(to, 4))) {
+		dev_err(&mtd->dev, "unaligned write %lld %zd\n", to, len);
+		return -EINVAL;
+	}
+
+	idx = spi_get_region(spi, to);
+
+	dev_dbg(&mtd->dev, "writing region[%d] %s to %lld len %zd\n",
+		spi->regions[idx].id, spi->regions[idx].name, to, len);
+
+	if (idx >= spi->nregions) {
+		dev_err(&mtd->dev, "out of range");
+		return -ERANGE;
+	}
+
+	to -= spi->regions[idx].offset;
+	region = spi->regions[idx].id;
+	if (len > spi->regions[idx].size - to)
+		len = spi->regions[idx].size - to;
+
+	ret = spi_write(spi, region, to, len, buf);
+	if (ret < 0) {
+		dev_dbg(&mtd->dev, "write failed with %zd\n", ret);
+		return ret;
+	}
+
+	*retlen = ret;
 
 	return 0;
 }
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFC PATCH 8/9] drm/i915/spi: serialize spi access

[Tomas Winkler]

The SPI regions cannot be accessed in parallel because for each
region the region selector has to be set. Add a mutex to prevent
parallel access.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 32 +++++++++++++++++++++---
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
index 1e8a40339e6d..9de49d00297d 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -20,6 +20,7 @@
 
 struct i915_spi {
 	struct mtd_info mtd;
+	struct mutex lock; /* region access lock */
 	void __iomem *base;
 	size_t size;
 	unsigned int nregions;
@@ -354,6 +355,7 @@ static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
 	loff_t from;
 	size_t len;
 	size_t total_len;
+	int ret = 0;
 
 	if (!mtd || !info)
 		return -EINVAL;
@@ -370,18 +372,23 @@ static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
 	total_len = info->len;
 	addr = info->addr;
 
+	if (!mutex_trylock(&spi->lock))
+		return -EBUSY;
+
 	while (total_len > 0) {
 		if (!IS_ALIGNED(addr, SZ_4K) || !IS_ALIGNED(total_len, SZ_4K)) {
 			dev_err(&mtd->dev, "unaligned erase %llx %zx\n", addr, total_len);
 			info->fail_addr = addr;
-			return -ERANGE;
+			ret = -ERANGE;
+			goto out;
 		}
 
 		idx = spi_get_region(spi, addr);
 		if (idx >= spi->nregions) {
 			dev_err(&mtd->dev, "out of range");
 			info->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
-			return -ERANGE;
+			ret = -ERANGE;
+			goto out;
 		}
 
 		from = addr - spi->regions[idx].offset;
@@ -397,14 +404,17 @@ static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
 		if (bytes < 0) {
 			dev_dbg(&mtd->dev, "erase failed with %zd\n", bytes);
 			info->fail_addr += spi->regions[idx].offset;
-			return bytes;
+			ret = bytes;
+			goto out;
 		}
 
 		addr += len;
 		total_len -= len;
 	}
 
-	return 0;
+out:
+	mutex_unlock(&spi->lock);
+	return ret;
 }
 
 static int i915_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
@@ -440,14 +450,19 @@ static int i915_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
 	if (len > spi->regions[idx].size - from)
 		len = spi->regions[idx].size - from;
 
+	if (!mutex_trylock(&spi->lock))
+		return -EBUSY;
+
 	ret = spi_read(spi, region, from, len, buf);
 	if (ret < 0) {
 		dev_dbg(&mtd->dev, "read failed with %zd\n", ret);
+		mutex_unlock(&spi->lock);
 		return ret;
 	}
 
 	*retlen = ret;
 
+	mutex_unlock(&spi->lock);
 	return 0;
 }
 
@@ -484,14 +499,19 @@ static int i915_spi_write(struct mtd_info *mtd, loff_t to, size_t len,
 	if (len > spi->regions[idx].size - to)
 		len = spi->regions[idx].size - to;
 
+	if (!mutex_trylock(&spi->lock))
+		return -EBUSY;
+
 	ret = spi_write(spi, region, to, len, buf);
 	if (ret < 0) {
 		dev_dbg(&mtd->dev, "write failed with %zd\n", ret);
+		mutex_unlock(&spi->lock);
 		return ret;
 	}
 
 	*retlen = ret;
 
+	mutex_unlock(&spi->lock);
 	return 0;
 }
 
@@ -505,6 +525,8 @@ static int i915_spi_init_mtd(struct i915_spi *spi, struct device *device,
 
 	dev_dbg(device, "registering with mtd\n");
 
+	mutex_init(&spi->lock);
+
 	spi->mtd.owner = THIS_MODULE;
 	spi->mtd.dev.parent = device;
 	spi->mtd.flags = MTD_CAP_NORFLASH | MTD_WRITEABLE;
@@ -630,6 +652,8 @@ static int i915_spi_remove(struct platform_device *platdev)
 
 	mtd_device_unregister(&spi->mtd);
 
+	mutex_destroy(&spi->lock);
+
 	platform_set_drvdata(platdev, NULL);
 
 	return 0;
-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[Intel-gfx] [RFC PATCH 8/9] drm/i915/spi: serialize spi access

[Tomas Winkler]

The SPI regions cannot be accessed in parallel because for each
region the region selector has to be set. Add a mutex to prevent
parallel access.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/gpu/drm/i915/spi/intel_spi_drv.c | 32 +++++++++++++++++++++---
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/spi/intel_spi_drv.c b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
index 1e8a40339e6d..9de49d00297d 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi_drv.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi_drv.c
@@ -20,6 +20,7 @@
 
 struct i915_spi {
 	struct mtd_info mtd;
+	struct mutex lock; /* region access lock */
 	void __iomem *base;
 	size_t size;
 	unsigned int nregions;
@@ -354,6 +355,7 @@ static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
 	loff_t from;
 	size_t len;
 	size_t total_len;
+	int ret = 0;
 
 	if (!mtd || !info)
 		return -EINVAL;
@@ -370,18 +372,23 @@ static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
 	total_len = info->len;
 	addr = info->addr;
 
+	if (!mutex_trylock(&spi->lock))
+		return -EBUSY;
+
 	while (total_len > 0) {
 		if (!IS_ALIGNED(addr, SZ_4K) || !IS_ALIGNED(total_len, SZ_4K)) {
 			dev_err(&mtd->dev, "unaligned erase %llx %zx\n", addr, total_len);
 			info->fail_addr = addr;
-			return -ERANGE;
+			ret = -ERANGE;
+			goto out;
 		}
 
 		idx = spi_get_region(spi, addr);
 		if (idx >= spi->nregions) {
 			dev_err(&mtd->dev, "out of range");
 			info->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
-			return -ERANGE;
+			ret = -ERANGE;
+			goto out;
 		}
 
 		from = addr - spi->regions[idx].offset;
@@ -397,14 +404,17 @@ static int i915_spi_erase(struct mtd_info *mtd, struct erase_info *info)
 		if (bytes < 0) {
 			dev_dbg(&mtd->dev, "erase failed with %zd\n", bytes);
 			info->fail_addr += spi->regions[idx].offset;
-			return bytes;
+			ret = bytes;
+			goto out;
 		}
 
 		addr += len;
 		total_len -= len;
 	}
 
-	return 0;
+out:
+	mutex_unlock(&spi->lock);
+	return ret;
 }
 
 static int i915_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
@@ -440,14 +450,19 @@ static int i915_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
 	if (len > spi->regions[idx].size - from)
 		len = spi->regions[idx].size - from;
 
+	if (!mutex_trylock(&spi->lock))
+		return -EBUSY;
+
 	ret = spi_read(spi, region, from, len, buf);
 	if (ret < 0) {
 		dev_dbg(&mtd->dev, "read failed with %zd\n", ret);
+		mutex_unlock(&spi->lock);
 		return ret;
 	}
 
 	*retlen = ret;
 
+	mutex_unlock(&spi->lock);
 	return 0;
 }
 
@@ -484,14 +499,19 @@ static int i915_spi_write(struct mtd_info *mtd, loff_t to, size_t len,
 	if (len > spi->regions[idx].size - to)
 		len = spi->regions[idx].size - to;
 
+	if (!mutex_trylock(&spi->lock))
+		return -EBUSY;
+
 	ret = spi_write(spi, region, to, len, buf);
 	if (ret < 0) {
 		dev_dbg(&mtd->dev, "write failed with %zd\n", ret);
+		mutex_unlock(&spi->lock);
 		return ret;
 	}
 
 	*retlen = ret;
 
+	mutex_unlock(&spi->lock);
 	return 0;
 }
 
@@ -505,6 +525,8 @@ static int i915_spi_init_mtd(struct i915_spi *spi, struct device *device,
 
 	dev_dbg(device, "registering with mtd\n");
 
+	mutex_init(&spi->lock);
+
 	spi->mtd.owner = THIS_MODULE;
 	spi->mtd.dev.parent = device;
 	spi->mtd.flags = MTD_CAP_NORFLASH | MTD_WRITEABLE;
@@ -630,6 +652,8 @@ static int i915_spi_remove(struct platform_device *platdev)
 
 	mtd_device_unregister(&spi->mtd);
 
+	mutex_destroy(&spi->lock);
+
 	platform_set_drvdata(platdev, NULL);
 
 	return 0;
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFC PATCH 9/9] mtd: use refcount to prevent corruption

[Tomas Winkler]

When underlying device is removed mtd core will crash
in case user space is holding open handle.
Need to use proper refcounting so device is release
only when has no users.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/mtd/mtdcore.c   | 63 +++++++++++++++++++++++++----------------
 drivers/mtd/mtdcore.h   |  1 +
 drivers/mtd/mtdpart.c   | 13 +++++----
 include/linux/mtd/mtd.h |  2 +-
 4 files changed, 47 insertions(+), 32 deletions(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 2d6423d89a17..a3dacc7104a9 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -93,9 +93,31 @@ static void mtd_release(struct device *dev)
 	dev_t index = MTD_DEVT(mtd->index);
 
 	/* remove /dev/mtdXro node */
+	if (mtd_is_partition(mtd))
+		release_mtd_partition(mtd);
+
 	device_destroy(&mtd_class, index + 1);
 }
 
+static void mtd_device_release(struct kref *kref)
+{
+	struct mtd_info *mtd = container_of(kref, struct mtd_info, refcnt);
+
+	pr_debug("%s %s\n", __func__, mtd->name);
+
+	if (mtd->nvmem) {
+		nvmem_unregister(mtd->nvmem);
+		mtd->nvmem = NULL;
+	}
+
+	idr_remove(&mtd_idr, mtd->index);
+	of_node_put(mtd_get_of_node(mtd));
+
+	device_unregister(&mtd->dev);
+
+	module_put(THIS_MODULE);
+}
+
 static ssize_t mtd_type_show(struct device *dev,
 		struct device_attribute *attr, char *buf)
 {
@@ -619,7 +641,7 @@ int add_mtd_device(struct mtd_info *mtd)
 	}
 
 	mtd->index = i;
-	mtd->usecount = 0;
+	kref_init(&mtd->refcnt);
 
 	/* default value if not set by driver */
 	if (mtd->bitflip_threshold == 0)
@@ -719,6 +741,8 @@ int del_mtd_device(struct mtd_info *mtd)
 	int ret;
 	struct mtd_notifier *not;
 
+	pr_debug("%s %s\n", __func__, mtd->name);
+
 	mutex_lock(&mtd_table_mutex);
 
 	debugfs_remove_recursive(mtd->dbg.dfs_dir);
@@ -733,23 +757,8 @@ int del_mtd_device(struct mtd_info *mtd)
 	list_for_each_entry(not, &mtd_notifiers, list)
 		not->remove(mtd);
 
-	if (mtd->usecount) {
-		printk(KERN_NOTICE "Removing MTD device #%d (%s) with use count %d\n",
-		       mtd->index, mtd->name, mtd->usecount);
-		ret = -EBUSY;
-	} else {
-		/* Try to remove the NVMEM provider */
-		if (mtd->nvmem)
-			nvmem_unregister(mtd->nvmem);
-
-		device_unregister(&mtd->dev);
-
-		idr_remove(&mtd_idr, mtd->index);
-		of_node_put(mtd_get_of_node(mtd));
-
-		module_put(THIS_MODULE);
-		ret = 0;
-	}
+	kref_put(&mtd->refcnt, mtd_device_release);
+	ret = 0;
 
 out_error:
 	mutex_unlock(&mtd_table_mutex);
@@ -984,20 +993,23 @@ int __get_mtd_device(struct mtd_info *mtd)
 	if (!try_module_get(master->owner))
 		return -ENODEV;
 
+	kref_get(&mtd->refcnt);
+	pr_debug("get mtd %s %d\n", mtd->name, kref_read(&mtd->refcnt));
+
 	if (master->_get_device) {
 		err = master->_get_device(mtd);
 
 		if (err) {
+			kref_put(&mtd->refcnt, mtd_device_release);
 			module_put(master->owner);
 			return err;
 		}
 	}
 
-	master->usecount++;
-
 	while (mtd->parent) {
-		mtd->usecount++;
 		mtd = mtd->parent;
+		kref_get(&mtd->refcnt);
+		pr_debug("get mtd %s %d\n", mtd->name, kref_read(&mtd->refcnt));
 	}
 
 	return 0;
@@ -1055,14 +1067,15 @@ void __put_mtd_device(struct mtd_info *mtd)
 {
 	struct mtd_info *master = mtd_get_master(mtd);
 
+	kref_put(&mtd->refcnt, mtd_device_release);
+	pr_debug("put mtd %s %d\n", mtd->name, kref_read(&mtd->refcnt));
+
 	while (mtd->parent) {
-		--mtd->usecount;
-		BUG_ON(mtd->usecount < 0);
 		mtd = mtd->parent;
+		kref_put(&mtd->refcnt, mtd_device_release);
+		pr_debug("put mtd %s %d\n", mtd->name, kref_read(&mtd->refcnt));
 	}
 
-	master->usecount--;
-
 	if (master->_put_device)
 		master->_put_device(master);
 
diff --git a/drivers/mtd/mtdcore.h b/drivers/mtd/mtdcore.h
index b5eefeabf310..b014861a06a6 100644
--- a/drivers/mtd/mtdcore.h
+++ b/drivers/mtd/mtdcore.h
@@ -12,6 +12,7 @@ int __must_check add_mtd_device(struct mtd_info *mtd);
 int del_mtd_device(struct mtd_info *mtd);
 int add_mtd_partitions(struct mtd_info *, const struct mtd_partition *, int);
 int del_mtd_partitions(struct mtd_info *);
+void release_mtd_partition(struct mtd_info *mtd);
 
 struct mtd_partitions;
 
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 12ca4f19cb14..6d70b5d0e663 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -27,10 +27,17 @@
 
 static inline void free_partition(struct mtd_info *mtd)
 {
+	pr_err("free_partition \"%s\"\n", mtd->name);
 	kfree(mtd->name);
 	kfree(mtd);
 }
 
+void release_mtd_partition(struct mtd_info *mtd)
+{
+	list_del_init(&mtd->part.node);
+	free_partition(mtd);
+}
+
 static struct mtd_info *allocate_partition(struct mtd_info *parent,
 					   const struct mtd_partition *part,
 					   int partno, uint64_t cur_offset)
@@ -313,9 +320,6 @@ static int __mtd_del_partition(struct mtd_info *mtd)
 	if (err)
 		return err;
 
-	list_del(&child->part.node);
-	free_partition(mtd);
-
 	return 0;
 }
 
@@ -341,9 +345,6 @@ static int __del_mtd_partitions(struct mtd_info *mtd)
 			err = ret;
 			continue;
 		}
-
-		list_del(&child->part.node);
-		free_partition(child);
 	}
 
 	return err;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 157357ec1441..1217c9d8d69d 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -373,7 +373,7 @@ struct mtd_info {
 
 	struct module *owner;
 	struct device dev;
-	int usecount;
+	struct kref refcnt;
 	struct mtd_debug_info dbg;
 	struct nvmem_device *nvmem;
 
-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[Intel-gfx] [RFC PATCH 9/9] mtd: use refcount to prevent corruption

[Tomas Winkler]

When underlying device is removed mtd core will crash
in case user space is holding open handle.
Need to use proper refcounting so device is release
only when has no users.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/mtd/mtdcore.c   | 63 +++++++++++++++++++++++++----------------
 drivers/mtd/mtdcore.h   |  1 +
 drivers/mtd/mtdpart.c   | 13 +++++----
 include/linux/mtd/mtd.h |  2 +-
 4 files changed, 47 insertions(+), 32 deletions(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 2d6423d89a17..a3dacc7104a9 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -93,9 +93,31 @@ static void mtd_release(struct device *dev)
 	dev_t index = MTD_DEVT(mtd->index);
 
 	/* remove /dev/mtdXro node */
+	if (mtd_is_partition(mtd))
+		release_mtd_partition(mtd);
+
 	device_destroy(&mtd_class, index + 1);
 }
 
+static void mtd_device_release(struct kref *kref)
+{
+	struct mtd_info *mtd = container_of(kref, struct mtd_info, refcnt);
+
+	pr_debug("%s %s\n", __func__, mtd->name);
+
+	if (mtd->nvmem) {
+		nvmem_unregister(mtd->nvmem);
+		mtd->nvmem = NULL;
+	}
+
+	idr_remove(&mtd_idr, mtd->index);
+	of_node_put(mtd_get_of_node(mtd));
+
+	device_unregister(&mtd->dev);
+
+	module_put(THIS_MODULE);
+}
+
 static ssize_t mtd_type_show(struct device *dev,
 		struct device_attribute *attr, char *buf)
 {
@@ -619,7 +641,7 @@ int add_mtd_device(struct mtd_info *mtd)
 	}
 
 	mtd->index = i;
-	mtd->usecount = 0;
+	kref_init(&mtd->refcnt);
 
 	/* default value if not set by driver */
 	if (mtd->bitflip_threshold == 0)
@@ -719,6 +741,8 @@ int del_mtd_device(struct mtd_info *mtd)
 	int ret;
 	struct mtd_notifier *not;
 
+	pr_debug("%s %s\n", __func__, mtd->name);
+
 	mutex_lock(&mtd_table_mutex);
 
 	debugfs_remove_recursive(mtd->dbg.dfs_dir);
@@ -733,23 +757,8 @@ int del_mtd_device(struct mtd_info *mtd)
 	list_for_each_entry(not, &mtd_notifiers, list)
 		not->remove(mtd);
 
-	if (mtd->usecount) {
-		printk(KERN_NOTICE "Removing MTD device #%d (%s) with use count %d\n",
-		       mtd->index, mtd->name, mtd->usecount);
-		ret = -EBUSY;
-	} else {
-		/* Try to remove the NVMEM provider */
-		if (mtd->nvmem)
-			nvmem_unregister(mtd->nvmem);
-
-		device_unregister(&mtd->dev);
-
-		idr_remove(&mtd_idr, mtd->index);
-		of_node_put(mtd_get_of_node(mtd));
-
-		module_put(THIS_MODULE);
-		ret = 0;
-	}
+	kref_put(&mtd->refcnt, mtd_device_release);
+	ret = 0;
 
 out_error:
 	mutex_unlock(&mtd_table_mutex);
@@ -984,20 +993,23 @@ int __get_mtd_device(struct mtd_info *mtd)
 	if (!try_module_get(master->owner))
 		return -ENODEV;
 
+	kref_get(&mtd->refcnt);
+	pr_debug("get mtd %s %d\n", mtd->name, kref_read(&mtd->refcnt));
+
 	if (master->_get_device) {
 		err = master->_get_device(mtd);
 
 		if (err) {
+			kref_put(&mtd->refcnt, mtd_device_release);
 			module_put(master->owner);
 			return err;
 		}
 	}
 
-	master->usecount++;
-
 	while (mtd->parent) {
-		mtd->usecount++;
 		mtd = mtd->parent;
+		kref_get(&mtd->refcnt);
+		pr_debug("get mtd %s %d\n", mtd->name, kref_read(&mtd->refcnt));
 	}
 
 	return 0;
@@ -1055,14 +1067,15 @@ void __put_mtd_device(struct mtd_info *mtd)
 {
 	struct mtd_info *master = mtd_get_master(mtd);
 
+	kref_put(&mtd->refcnt, mtd_device_release);
+	pr_debug("put mtd %s %d\n", mtd->name, kref_read(&mtd->refcnt));
+
 	while (mtd->parent) {
-		--mtd->usecount;
-		BUG_ON(mtd->usecount < 0);
 		mtd = mtd->parent;
+		kref_put(&mtd->refcnt, mtd_device_release);
+		pr_debug("put mtd %s %d\n", mtd->name, kref_read(&mtd->refcnt));
 	}
 
-	master->usecount--;
-
 	if (master->_put_device)
 		master->_put_device(master);
 
diff --git a/drivers/mtd/mtdcore.h b/drivers/mtd/mtdcore.h
index b5eefeabf310..b014861a06a6 100644
--- a/drivers/mtd/mtdcore.h
+++ b/drivers/mtd/mtdcore.h
@@ -12,6 +12,7 @@ int __must_check add_mtd_device(struct mtd_info *mtd);
 int del_mtd_device(struct mtd_info *mtd);
 int add_mtd_partitions(struct mtd_info *, const struct mtd_partition *, int);
 int del_mtd_partitions(struct mtd_info *);
+void release_mtd_partition(struct mtd_info *mtd);
 
 struct mtd_partitions;
 
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 12ca4f19cb14..6d70b5d0e663 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -27,10 +27,17 @@
 
 static inline void free_partition(struct mtd_info *mtd)
 {
+	pr_err("free_partition \"%s\"\n", mtd->name);
 	kfree(mtd->name);
 	kfree(mtd);
 }
 
+void release_mtd_partition(struct mtd_info *mtd)
+{
+	list_del_init(&mtd->part.node);
+	free_partition(mtd);
+}
+
 static struct mtd_info *allocate_partition(struct mtd_info *parent,
 					   const struct mtd_partition *part,
 					   int partno, uint64_t cur_offset)
@@ -313,9 +320,6 @@ static int __mtd_del_partition(struct mtd_info *mtd)
 	if (err)
 		return err;
 
-	list_del(&child->part.node);
-	free_partition(mtd);
-
 	return 0;
 }
 
@@ -341,9 +345,6 @@ static int __del_mtd_partitions(struct mtd_info *mtd)
 			err = ret;
 			continue;
 		}
-
-		list_del(&child->part.node);
-		free_partition(child);
 	}
 
 	return err;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 157357ec1441..1217c9d8d69d 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -373,7 +373,7 @@ struct mtd_info {
 
 	struct module *owner;
 	struct device dev;
-	int usecount;
+	struct kref refcnt;
 	struct mtd_debug_info dbg;
 	struct nvmem_device *nvmem;
 
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/spi: discrete graphics internal spi

[Patchwork]

== Series Details ==

Series: drm/i915/spi: discrete graphics internal spi
URL   : https://patchwork.freedesktop.org/series/87137/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
00cd2f532d55 drm/i915/spi: add spi device for discrete graphics
-:115: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#115: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 144 lines checked
898dd46b903c drm/i915/spi: intel_spi_region map
e863e8ed0f60 drm/i915/spi: add driver for on-die spi device
-:41: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#41: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 133 lines checked
38d4aaea57cb drm/i915/spi: implement region enumeration
09c90ea9056f drm/i915/spi: implement spi access functions
b0e8bcfbf9b1 drm/i915/spi: spi register with mtd
bf56e1ed210e drm/i915/spi: mtd: implement access handlers
e19e4be7b8a6 drm/i915/spi: serialize spi access
a88bc6332c0e mtd: use refcount to prevent corruption


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/spi: discrete graphics internal spi

[Patchwork]

== Series Details ==

Series: drm/i915/spi: discrete graphics internal spi
URL   : https://patchwork.freedesktop.org/series/87137/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 279040
+drivers/gpu/drm/i915/i915_perf.c:1437:15: warning: memset with byte count of 16777216
+drivers/gpu/drm/i915/i915_perf.c:1491:15: warning: memset with byte count of 16777216
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/spi: discrete graphics internal spi

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 2908 bytes --]

== Series Details ==

Series: drm/i915/spi: discrete graphics internal spi
URL   : https://patchwork.freedesktop.org/series/87137/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9779 -> Patchwork_19688
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/index.html

Known issues
------------

  Here are the changes found in Patchwork_19688 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@i915_selftest@live@client:
    - fi-glk-dsi:         [PASS][1] -> [DMESG-FAIL][2] ([i915#3047])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/fi-glk-dsi/igt@i915_selftest@live@client.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/fi-glk-dsi/igt@i915_selftest@live@client.html

  * igt@prime_vgem@basic-userptr:
    - fi-tgl-y:           [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar issue
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/fi-tgl-y/igt@prime_vgem@basic-userptr.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/fi-tgl-y/igt@prime_vgem@basic-userptr.html

  
#### Possible fixes ####

  * igt@prime_vgem@basic-fence-flip:
    - fi-tgl-y:           [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +2 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/fi-tgl-y/igt@prime_vgem@basic-fence-flip.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/fi-tgl-y/igt@prime_vgem@basic-fence-flip.html

  
  [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (45 -> 40)
------------------------------

  Missing    (5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9779 -> Patchwork_19688

  CI-20190529: 20190529
  CI_DRM_9779: 775dbe8d5e041442fcadf63894468a63582a87a2 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6004: fe9ac2aeffc1828c6d61763a611a44fbd450aa96 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19688: a88bc6332c0e24c204e6aae6a0d3eb1df32cbbe0 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a88bc6332c0e mtd: use refcount to prevent corruption
e19e4be7b8a6 drm/i915/spi: serialize spi access
bf56e1ed210e drm/i915/spi: mtd: implement access handlers
b0e8bcfbf9b1 drm/i915/spi: spi register with mtd
09c90ea9056f drm/i915/spi: implement spi access functions
38d4aaea57cb drm/i915/spi: implement region enumeration
e863e8ed0f60 drm/i915/spi: add driver for on-die spi device
898dd46b903c drm/i915/spi: intel_spi_region map
00cd2f532d55 drm/i915/spi: add spi device for discrete graphics

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/index.html

[-- Attachment #1.2: Type: text/html, Size: 3680 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/spi: discrete graphics internal spi

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 30266 bytes --]

== Series Details ==

Series: drm/i915/spi: discrete graphics internal spi
URL   : https://patchwork.freedesktop.org/series/87137/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9779_full -> Patchwork_19688_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_19688_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_19688_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_19688_full:

### IGT changes ###

#### Possible regressions ####

  * igt@sysfs_clients@busy@bcs0:
    - shard-skl:          NOTRUN -> [FAIL][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl10/igt@sysfs_clients@busy@bcs0.html

  
Known issues
------------

  Here are the changes found in Patchwork_19688_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@feature_discovery@psr2:
    - shard-iclb:         [PASS][2] -> [SKIP][3] ([i915#658])
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-iclb2/igt@feature_discovery@psr2.html
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb4/igt@feature_discovery@psr2.html

  * igt@gem_ctx_persistence@engines-hostile:
    - shard-hsw:          NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-hsw8/igt@gem_ctx_persistence@engines-hostile.html

  * igt@gem_ctx_persistence@engines-persistence:
    - shard-snb:          NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-snb7/igt@gem_ctx_persistence@engines-persistence.html

  * igt@gem_eio@unwedge-stress:
    - shard-tglb:         [PASS][6] -> [TIMEOUT][7] ([i915#1037] / [i915#3063])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-tglb1/igt@gem_eio@unwedge-stress.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-tglb7/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
    - shard-tglb:         [PASS][8] -> [FAIL][9] ([i915#2846])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-tglb3/igt@gem_exec_fair@basic-deadline.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-tglb5/igt@gem_exec_fair@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
    - shard-kbl:          NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@gem_exec_fair@basic-none-solo@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
    - shard-tglb:         [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-tglb2/igt@gem_exec_fair@basic-pace@vcs0.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-tglb6/igt@gem_exec_fair@basic-pace@vcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
    - shard-iclb:         NOTRUN -> [FAIL][13] ([i915#2842])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb1/igt@gem_exec_fair@basic-pace@vcs1.html
    - shard-kbl:          [PASS][14] -> [SKIP][15] ([fdo#109271])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-kbl1/igt@gem_exec_fair@basic-pace@vcs1.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl6/igt@gem_exec_fair@basic-pace@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-glk:          [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar issue
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-glk5/igt@gem_exec_fair@basic-throttle@rcs0.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-glk8/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gem_exec_reloc@basic-parallel:
    - shard-apl:          NOTRUN -> [TIMEOUT][18] ([i915#1729])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl2/igt@gem_exec_reloc@basic-parallel.html

  * igt@gem_exec_schedule@u-semaphore-codependency:
    - shard-skl:          [PASS][19] -> [DMESG-WARN][20] ([i915#1610])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl5/igt@gem_exec_schedule@u-semaphore-codependency.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl10/igt@gem_exec_schedule@u-semaphore-codependency.html

  * igt@gem_huc_copy@huc-copy:
    - shard-kbl:          NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#2190])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@gem_huc_copy@huc-copy.html

  * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled:
    - shard-kbl:          NOTRUN -> [SKIP][22] ([fdo#109271]) +168 similar issues
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl6/igt@gem_render_copy@x-tiled-to-vebox-yf-tiled.html

  * igt@gem_userptr_blits@input-checking:
    - shard-kbl:          NOTRUN -> [DMESG-WARN][23] ([i915#3002])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@gem_userptr_blits@input-checking.html

  * igt@gem_userptr_blits@process-exit-mmap-busy@wc:
    - shard-apl:          NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#1699]) +3 similar issues
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl2/igt@gem_userptr_blits@process-exit-mmap-busy@wc.html

  * igt@gem_userptr_blits@process-exit-mmap@gtt:
    - shard-kbl:          NOTRUN -> [SKIP][25] ([fdo#109271] / [i915#1699]) +3 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl6/igt@gem_userptr_blits@process-exit-mmap@gtt.html

  * igt@gem_workarounds@suspend-resume-context:
    - shard-skl:          [PASS][26] -> [INCOMPLETE][27] ([i915#198] / [i915#2295])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl8/igt@gem_workarounds@suspend-resume-context.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl9/igt@gem_workarounds@suspend-resume-context.html
    - shard-kbl:          [PASS][28] -> [DMESG-WARN][29] ([i915#180])
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-kbl2/igt@gem_workarounds@suspend-resume-context.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl4/igt@gem_workarounds@suspend-resume-context.html

  * igt@gen7_exec_parse@cmd-crossing-page:
    - shard-tglb:         NOTRUN -> [SKIP][30] ([fdo#109289])
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-tglb2/igt@gen7_exec_parse@cmd-crossing-page.html
    - shard-iclb:         NOTRUN -> [SKIP][31] ([fdo#109289])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb2/igt@gen7_exec_parse@cmd-crossing-page.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-kbl:          NOTRUN -> [FAIL][32] ([i915#454])
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@i915_pm_dc@dc6-dpms.html

  * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-hdmi-a:
    - shard-glk:          NOTRUN -> [SKIP][33] ([fdo#109271] / [i915#1937])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-glk2/igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-hdmi-a.html

  * igt@i915_suspend@sysfs-reader:
    - shard-apl:          NOTRUN -> [DMESG-WARN][34] ([i915#180]) +2 similar issues
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl8/igt@i915_suspend@sysfs-reader.html

  * igt@kms_async_flips@alternate-sync-async-flip:
    - shard-skl:          [PASS][35] -> [FAIL][36] ([i915#2521])
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl1/igt@kms_async_flips@alternate-sync-async-flip.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl4/igt@kms_async_flips@alternate-sync-async-flip.html

  * igt@kms_big_fb@x-tiled-16bpp-rotate-90:
    - shard-tglb:         NOTRUN -> [SKIP][37] ([fdo#111614])
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-tglb2/igt@kms_big_fb@x-tiled-16bpp-rotate-90.html
    - shard-iclb:         NOTRUN -> [SKIP][38] ([fdo#110725] / [fdo#111614])
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb2/igt@kms_big_fb@x-tiled-16bpp-rotate-90.html

  * igt@kms_big_fb@yf-tiled-8bpp-rotate-90:
    - shard-snb:          NOTRUN -> [SKIP][39] ([fdo#109271]) +114 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-snb7/igt@kms_big_fb@yf-tiled-8bpp-rotate-90.html

  * igt@kms_big_joiner@basic:
    - shard-kbl:          NOTRUN -> [SKIP][40] ([fdo#109271] / [i915#2705]) +1 similar issue
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl2/igt@kms_big_joiner@basic.html

  * igt@kms_chamelium@dp-hpd-storm-disable:
    - shard-skl:          NOTRUN -> [SKIP][41] ([fdo#109271] / [fdo#111827]) +3 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl10/igt@kms_chamelium@dp-hpd-storm-disable.html

  * igt@kms_chamelium@hdmi-hpd-enable-disable-mode:
    - shard-snb:          NOTRUN -> [SKIP][42] ([fdo#109271] / [fdo#111827]) +7 similar issues
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-snb2/igt@kms_chamelium@hdmi-hpd-enable-disable-mode.html

  * igt@kms_chamelium@vga-edid-read:
    - shard-iclb:         NOTRUN -> [SKIP][43] ([fdo#109284] / [fdo#111827]) +2 similar issues
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb2/igt@kms_chamelium@vga-edid-read.html

  * igt@kms_chamelium@vga-hpd-enable-disable-mode:
    - shard-glk:          NOTRUN -> [SKIP][44] ([fdo#109271] / [fdo#111827]) +4 similar issues
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-glk2/igt@kms_chamelium@vga-hpd-enable-disable-mode.html

  * igt@kms_chamelium@vga-hpd-for-each-pipe:
    - shard-kbl:          NOTRUN -> [SKIP][45] ([fdo#109271] / [fdo#111827]) +20 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl6/igt@kms_chamelium@vga-hpd-for-each-pipe.html

  * igt@kms_color_chamelium@pipe-c-ctm-0-25:
    - shard-apl:          NOTRUN -> [SKIP][46] ([fdo#109271] / [fdo#111827]) +17 similar issues
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl7/igt@kms_color_chamelium@pipe-c-ctm-0-25.html
    - shard-tglb:         NOTRUN -> [SKIP][47] ([fdo#109284] / [fdo#111827]) +3 similar issues
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-tglb2/igt@kms_color_chamelium@pipe-c-ctm-0-25.html

  * igt@kms_color_chamelium@pipe-d-gamma:
    - shard-iclb:         NOTRUN -> [SKIP][48] ([fdo#109278] / [fdo#109284] / [fdo#111827])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb2/igt@kms_color_chamelium@pipe-d-gamma.html

  * igt@kms_content_protection@atomic-dpms:
    - shard-kbl:          NOTRUN -> [TIMEOUT][49] ([i915#1319]) +1 similar issue
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@kms_content_protection@atomic-dpms.html

  * igt@kms_content_protection@uevent:
    - shard-kbl:          NOTRUN -> [FAIL][50] ([i915#2105])
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl6/igt@kms_content_protection@uevent.html

  * igt@kms_cursor_crc@pipe-b-cursor-64x21-random:
    - shard-skl:          [PASS][51] -> [FAIL][52] ([i915#54]) +8 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl9/igt@kms_cursor_crc@pipe-b-cursor-64x21-random.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl9/igt@kms_cursor_crc@pipe-b-cursor-64x21-random.html

  * igt@kms_cursor_crc@pipe-c-cursor-64x64-onscreen:
    - shard-skl:          NOTRUN -> [FAIL][53] ([i915#54])
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl10/igt@kms_cursor_crc@pipe-c-cursor-64x64-onscreen.html

  * igt@kms_cursor_crc@pipe-d-cursor-256x85-random:
    - shard-iclb:         NOTRUN -> [SKIP][54] ([fdo#109278]) +2 similar issues
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb2/igt@kms_cursor_crc@pipe-d-cursor-256x85-random.html

  * igt@kms_cursor_crc@pipe-d-cursor-64x64-sliding:
    - shard-apl:          NOTRUN -> [SKIP][55] ([fdo#109271]) +133 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl1/igt@kms_cursor_crc@pipe-d-cursor-64x64-sliding.html

  * igt@kms_cursor_edge_walk@pipe-d-64x64-top-edge:
    - shard-hsw:          NOTRUN -> [SKIP][56] ([fdo#109271] / [i915#533]) +3 similar issues
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-hsw8/igt@kms_cursor_edge_walk@pipe-d-64x64-top-edge.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
    - shard-glk:          [PASS][57] -> [FAIL][58] ([i915#72])
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-glk7/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-glk1/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html

  * igt@kms_cursor_legacy@pipe-d-single-bo:
    - shard-kbl:          NOTRUN -> [SKIP][59] ([fdo#109271] / [i915#533])
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl2/igt@kms_cursor_legacy@pipe-d-single-bo.html

  * igt@kms_flip@2x-flip-vs-expired-vblank@bc-hdmi-a1-hdmi-a2:
    - shard-glk:          [PASS][60] -> [FAIL][61] ([i915#2122])
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank@bc-hdmi-a1-hdmi-a2.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vblank@bc-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@plain-flip-fb-recreate@a-edp1:
    - shard-skl:          [PASS][62] -> [FAIL][63] ([i915#2122])
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl3/igt@kms_flip@plain-flip-fb-recreate@a-edp1.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl1/igt@kms_flip@plain-flip-fb-recreate@a-edp1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs:
    - shard-kbl:          NOTRUN -> [FAIL][64] ([i915#2641])
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile:
    - shard-kbl:          NOTRUN -> [SKIP][65] ([fdo#109271] / [i915#2642])
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile.html

  * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile:
    - shard-apl:          NOTRUN -> [FAIL][66] ([i915#2641])
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile.html

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-shrfb-plflip-blt:
    - shard-iclb:         NOTRUN -> [SKIP][67] ([fdo#109280]) +2 similar issues
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb2/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-shrfb-plflip-blt.html
    - shard-tglb:         NOTRUN -> [SKIP][68] ([fdo#111825]) +2 similar issues
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-shrfb-plflip-blt.html

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-onoff:
    - shard-skl:          NOTRUN -> [SKIP][69] ([fdo#109271]) +40 similar issues
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl10/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-onoff.html

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-wc:
    - shard-glk:          NOTRUN -> [SKIP][70] ([fdo#109271]) +25 similar issues
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-glk2/igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-wc.html

  * igt@kms_hdr@static-swap:
    - shard-tglb:         NOTRUN -> [SKIP][71] ([i915#1187])
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-tglb2/igt@kms_hdr@static-swap.html
    - shard-iclb:         NOTRUN -> [SKIP][72] ([i915#1187])
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb2/igt@kms_hdr@static-swap.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
    - shard-apl:          NOTRUN -> [SKIP][73] ([fdo#109271] / [i915#533]) +1 similar issue
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
    - shard-kbl:          [PASS][74] -> [DMESG-WARN][75] ([i915#180] / [i915#533])
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-kbl7/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
    - shard-skl:          NOTRUN -> [FAIL][76] ([fdo#108145] / [i915#265])
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl10/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
    - shard-kbl:          NOTRUN -> [FAIL][77] ([fdo#108145] / [i915#265]) +1 similar issue
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@kms_plane_alpha_blend@pipe-c-alpha-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
    - shard-apl:          NOTRUN -> [FAIL][78] ([fdo#108145] / [i915#265]) +2 similar issues
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl2/igt@kms_plane_alpha_blend@pipe-c-alpha-basic.html

  * igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb:
    - shard-apl:          NOTRUN -> [FAIL][79] ([i915#265])
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl2/igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb.html

  * igt@kms_plane_lowres@pipe-b-tiling-yf:
    - shard-hsw:          NOTRUN -> [SKIP][80] ([fdo#109271]) +13 similar issues
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-hsw8/igt@kms_plane_lowres@pipe-b-tiling-yf.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2:
    - shard-apl:          NOTRUN -> [SKIP][81] ([fdo#109271] / [i915#658]) +2 similar issues
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-3:
    - shard-glk:          NOTRUN -> [SKIP][82] ([fdo#109271] / [i915#658])
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-glk2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-3.html

  * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3:
    - shard-kbl:          NOTRUN -> [SKIP][83] ([fdo#109271] / [i915#658]) +3 similar issues
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3.html

  * igt@kms_psr2_sf@plane-move-sf-dmg-area-1:
    - shard-skl:          NOTRUN -> [SKIP][84] ([fdo#109271] / [i915#658])
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl10/igt@kms_psr2_sf@plane-move-sf-dmg-area-1.html

  * igt@kms_psr@primary_page_flip:
    - shard-hsw:          NOTRUN -> [SKIP][85] ([fdo#109271] / [i915#1072])
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-hsw8/igt@kms_psr@primary_page_flip.html

  * igt@kms_psr@psr2_no_drrs:
    - shard-iclb:         [PASS][86] -> [SKIP][87] ([fdo#109441]) +2 similar issues
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb6/igt@kms_psr@psr2_no_drrs.html

  * igt@kms_sysfs_edid_timing:
    - shard-kbl:          NOTRUN -> [FAIL][88] ([IGT#2])
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl7/igt@kms_sysfs_edid_timing.html

  * igt@kms_writeback@writeback-check-output:
    - shard-apl:          NOTRUN -> [SKIP][89] ([fdo#109271] / [i915#2437])
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl2/igt@kms_writeback@writeback-check-output.html

  * igt@kms_writeback@writeback-fb-id:
    - shard-kbl:          NOTRUN -> [SKIP][90] ([fdo#109271] / [i915#2437])
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@kms_writeback@writeback-fb-id.html

  * igt@sysfs_clients@busy@vecs0:
    - shard-skl:          NOTRUN -> [FAIL][91] ([i915#3019])
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl10/igt@sysfs_clients@busy@vecs0.html

  * igt@sysfs_clients@recycle:
    - shard-kbl:          NOTRUN -> [FAIL][92] ([i915#3028])
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl1/igt@sysfs_clients@recycle.html

  * igt@sysfs_clients@sema-10@vcs0:
    - shard-apl:          NOTRUN -> [SKIP][93] ([fdo#109271] / [i915#3026]) +3 similar issues
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl3/igt@sysfs_clients@sema-10@vcs0.html

  * igt@sysfs_clients@split-10@vcs0:
    - shard-skl:          NOTRUN -> [SKIP][94] ([fdo#109271] / [i915#3026]) +3 similar issues
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl10/igt@sysfs_clients@split-10@vcs0.html

  * igt@sysfs_heartbeat_interval@mixed@bcs0:
    - shard-skl:          [PASS][95] -> [FAIL][96] ([i915#1731])
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl4/igt@sysfs_heartbeat_interval@mixed@bcs0.html
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl2/igt@sysfs_heartbeat_interval@mixed@bcs0.html

  
#### Possible fixes ####

  * igt@gem_exec_fair@basic-pace-share@rcs0:
    - shard-glk:          [FAIL][97] ([i915#2842]) -> [PASS][98]
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-glk4/igt@gem_exec_fair@basic-pace-share@rcs0.html
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-glk2/igt@gem_exec_fair@basic-pace-share@rcs0.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
    - shard-apl:          [FAIL][99] ([i915#2389]) -> [PASS][100]
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-apl3/igt@gem_exec_reloc@basic-many-active@rcs0.html
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl7/igt@gem_exec_reloc@basic-many-active@rcs0.html

  * igt@gem_exec_schedule@u-fairslice@bcs0:
    - shard-tglb:         [DMESG-WARN][101] ([i915#2803]) -> [PASS][102]
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-tglb8/igt@gem_exec_schedule@u-fairslice@bcs0.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-tglb2/igt@gem_exec_schedule@u-fairslice@bcs0.html

  * igt@gem_exec_schedule@u-fairslice@vcs0:
    - shard-iclb:         [DMESG-WARN][103] ([i915#2803]) -> [PASS][104]
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-iclb4/igt@gem_exec_schedule@u-fairslice@vcs0.html
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb2/igt@gem_exec_schedule@u-fairslice@vcs0.html

  * igt@gem_exec_schedule@u-fairslice@vecs0:
    - shard-apl:          [DMESG-WARN][105] ([i915#1610]) -> [PASS][106]
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-apl7/igt@gem_exec_schedule@u-fairslice@vecs0.html
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-apl7/igt@gem_exec_schedule@u-fairslice@vecs0.html

  * igt@i915_selftest@live@hangcheck:
    - shard-hsw:          [INCOMPLETE][107] ([i915#2782]) -> [PASS][108]
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-hsw4/igt@i915_selftest@live@hangcheck.html
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-hsw8/igt@i915_selftest@live@hangcheck.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-kbl:          [DMESG-WARN][109] ([i915#180]) -> [PASS][110] +1 similar issue
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-kbl7/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen:
    - shard-skl:          [FAIL][111] ([i915#54]) -> [PASS][112] +6 similar issues
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl4/igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen.html
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl2/igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1:
    - shard-skl:          [FAIL][113] ([i915#2122]) -> [PASS][114]
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl6/igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1.html
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl4/igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1.html

  * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-render:
    - shard-skl:          [DMESG-WARN][115] ([i915#1982]) -> [PASS][116]
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl7/igt@kms_frontbuffer_tracking@psr-rgb101010-draw-render.html
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl9/igt@kms_frontbuffer_tracking@psr-rgb101010-draw-render.html

  * igt@kms_hdr@bpc-switch-dpms:
    - shard-skl:          [FAIL][117] ([i915#1188]) -> [PASS][118]
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl8/igt@kms_hdr@bpc-switch-dpms.html
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl3/igt@kms_hdr@bpc-switch-dpms.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][119] ([fdo#108145] / [i915#265]) -> [PASS][120]
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
    - shard-iclb:         [SKIP][121] ([fdo#109441]) -> [PASS][122] +2 similar issues
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-iclb4/igt@kms_psr@psr2_primary_mmap_cpu.html
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@perf@polling:
    - shard-skl:          [FAIL][123] ([i915#1542]) -> [PASS][124]
   [123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl8/igt@perf@polling.html
   [124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-skl3/igt@perf@polling.html

  * igt@perf@polling-parameterized:
    - shard-glk:          [FAIL][125] ([i915#1542]) -> [PASS][126]
   [125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-glk2/igt@perf@polling-parameterized.html
   [126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-glk4/igt@perf@polling-parameterized.html
    - shard-iclb:         [FAIL][127] ([i915#1542]) -> [PASS][128]
   [127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-iclb5/igt@perf@polling-parameterized.html
   [128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb4/igt@perf@polling-parameterized.html

  * igt@sysfs_clients@busy@vcs0:
    - shard-iclb:         [FAIL][129] ([i915#3019]) -> [PASS][130]
   [129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-iclb8/igt@sysfs_clients@busy@vcs0.html
   [130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb8/igt@sysfs_clients@busy@vcs0.html

  * igt@sysfs_clients@recycle:
    - shard-snb:          [FAIL][131] ([i915#3028]) -> [PASS][132]
   [131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-snb2/igt@sysfs_clients@recycle.html
   [132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-snb5/igt@sysfs_clients@recycle.html
    - shard-hsw:          [FAIL][133] ([i915#3028]) -> [PASS][134]
   [133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-hsw1/igt@sysfs_clients@recycle.html
   [134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-hsw1/igt@sysfs_clients@recycle.html
    - shard-tglb:         [FAIL][135] ([i915#3028]) -> [PASS][136]
   [135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-tglb1/igt@sysfs_clients@recycle.html
   [136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-tglb8/igt@sysfs_clients@recycle.html

  
#### Warnings ####

  * igt@gem_exec_balancer@hang:
    - shard-iclb:         [INCOMPLETE][137] ([i915#1895] / [i915#2295]) -> [INCOMPLETE][138] ([i915#1895] / [i915#2295] / [i915#3031])
   [137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-iclb2/igt@gem_exec_balancer@hang.html
   [138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb4/igt@gem_exec_balancer@hang.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
    - shard-iclb:         [FAIL][139] ([i915#2842]) -> [FAIL][140] ([i915#2852])
   [139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-iclb6/igt@gem_exec_fair@basic-none-rrul@rcs0.html
   [140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/shard-iclb3/igt@gem_exec_fair@basic-none-rrul@rcs0.html

  * igt@i915_pm_dc@dc3co-vpb-simulation:
    - shard-skl:          [SKIP][141] ([fdo#109271] / [i915#658]) -> [INCOMPLETE][142] ([i915#198])
   [141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9779/shard-skl9/igt@i915_pm_dc@dc3co-vpb-simulation.html
   [142]:

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19688/index.html

[-- Attachment #1.2: Type: text/html, Size: 33610 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Richard Weinberger]

)On Tue, Feb 16, 2021 at 7:26 PM Tomas Winkler <tomas.winkler@intel.com> wrote:
> Because the graphic card may undergo reset at any time and basically hot
> unplug all its child devices, this series also provides a fix to the mtd
> framework to make the reset graceful.

Well, just because MTD does not work as you expect, it is not broken. :-)

In your case i915_spi_remove() blindly removes the MTD, this is not allowed.
You may remove the MTD only if there are no more users.

The current model in MTD is that the driver is in charge of all life
cycle management.
Using ->_get_device() and ->_put_device() a driver can implement
refcounting and deny
new users if the MTD is about to disappear.

In the upcoming MUSE driver that mechanism is used too.
MUSE allows to implement a MTD in userspace. So the FUSE server can disappear at
*any* time. Just like in your case. Even worse, it can be hostile.
In MUSE the MTD life time is tied to the FUSE connection object,
muse_mtd_get_device()
increments the FUSE connection refcount, and muse_mtd_put_device()
decrements it.
That means if the FUSE server disappears all of a sudden but the MTD
still has users,
the MTD will stay. But in this state no new references are allowed and
all MTD operations
of existing users will fail with -ENOTCONN (via FUSE).
As soon the last user is gone (can be userspace via /dev/mtd* or a
in-kernel user such as UBIFS),
the MTD will be removed.
For the full details, please see:
https://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git/tree/fs/fuse/muse.c?h=muse_v3#n1034

Is in your case *really* not possible to do it that way?

On the other hand, your last patch moves some part of the life cycle
management into MTD core.
The MTD will stay as long it has users.
But that's only one part. The driver is still in charge to make sure
that all operations
fail immediately and that no new users arrive.
If we want to do all in MTD core we'd have to do it like SCSI disks.
That means having devices states such as SDEV_RUNNING, SDEV_CANCEL,
SDEV_OFFLINE, ....
That way the MTD could be shutdown gracefully, first no new users are
allowed, then ongoing operations
will be cancelled, next all operation will fail with -EIO or such,
then the device is being removed from sysfs
and finally if the last user is gone, the MTD can be removed.

I'm not sure whether we want to take that path.

-- 
Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Richard Weinberger]

)On Tue, Feb 16, 2021 at 7:26 PM Tomas Winkler <tomas.winkler@intel.com> wrote:
> Because the graphic card may undergo reset at any time and basically hot
> unplug all its child devices, this series also provides a fix to the mtd
> framework to make the reset graceful.

Well, just because MTD does not work as you expect, it is not broken. :-)

In your case i915_spi_remove() blindly removes the MTD, this is not allowed.
You may remove the MTD only if there are no more users.

The current model in MTD is that the driver is in charge of all life
cycle management.
Using ->_get_device() and ->_put_device() a driver can implement
refcounting and deny
new users if the MTD is about to disappear.

In the upcoming MUSE driver that mechanism is used too.
MUSE allows to implement a MTD in userspace. So the FUSE server can disappear at
*any* time. Just like in your case. Even worse, it can be hostile.
In MUSE the MTD life time is tied to the FUSE connection object,
muse_mtd_get_device()
increments the FUSE connection refcount, and muse_mtd_put_device()
decrements it.
That means if the FUSE server disappears all of a sudden but the MTD
still has users,
the MTD will stay. But in this state no new references are allowed and
all MTD operations
of existing users will fail with -ENOTCONN (via FUSE).
As soon the last user is gone (can be userspace via /dev/mtd* or a
in-kernel user such as UBIFS),
the MTD will be removed.
For the full details, please see:
https://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git/tree/fs/fuse/muse.c?h=muse_v3#n1034

Is in your case *really* not possible to do it that way?

On the other hand, your last patch moves some part of the life cycle
management into MTD core.
The MTD will stay as long it has users.
But that's only one part. The driver is still in charge to make sure
that all operations
fail immediately and that no new users arrive.
If we want to do all in MTD core we'd have to do it like SCSI disks.
That means having devices states such as SDEV_RUNNING, SDEV_CANCEL,
SDEV_OFFLINE, ....
That way the MTD could be shutdown gracefully, first no new users are
allowed, then ongoing operations
will be cancelled, next all operation will fail with -EIO or such,
then the device is being removed from sysfs
and finally if the last user is gone, the MTD can be removed.

I'm not sure whether we want to take that path.

-- 
Thanks,
//richard
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> 
> )On Tue, Feb 16, 2021 at 7:26 PM Tomas Winkler <tomas.winkler@intel.com>
> wrote:
> > Because the graphic card may undergo reset at any time and basically
> > hot unplug all its child devices, this series also provides a fix to
> > the mtd framework to make the reset graceful.
> 
> Well, just because MTD does not work as you expect, it is not broken. :-)
I'm not saying it's broken by design it just didn't fit this use case. 
> 
> In your case i915_spi_remove() blindly removes the MTD, this is not allowed.
> You may remove the MTD only if there are no more users.

I'm not sure it's good idea to stall the removal on user space.
This is just asking for a deadlock as user space is not getting what it needs and may stall
I think it's better the user space will fail gracefully the hw is not accessible in that stage anyway. 
> 
> The current model in MTD is that the driver is in charge of all life cycle
> management.
> Using ->_get_device() and ->_put_device() a driver can implement
> refcounting and deny new users if the MTD is about to disappear.

Please note that this use case you are describing is still valid, I haven't removed _get_device() _put_device() handlers,
You can still stall the removal of mtd, If this is not that way it's a bug

> 
> In the upcoming MUSE driver that mechanism is used too.
> MUSE allows to implement a MTD in userspace. So the FUSE server can
> disappear at
> *any* time. Just like in your case. Even worse, it can be hostile.
> In MUSE the MTD life time is tied to the FUSE connection object,
> muse_mtd_get_device()
> increments the FUSE connection refcount, and muse_mtd_put_device()
> decrements it.
> That means if the FUSE server disappears all of a sudden but the MTD still has
> users, the MTD will stay. But in this state no new references are allowed and
> all MTD operations of existing users will fail with -ENOTCONN (via FUSE).
> As soon the last user is gone (can be userspace via /dev/mtd* or a in-kernel
> user such as UBIFS), the MTD will be removed.

But in our case whole i915 is taken hostage, it cannot reset because of misbehaving user space.

> For the full details, please see:
> https://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git/tree/fs/fuse/m
> use.c?h=muse_v3#n1034
> 
> Is in your case *really* not possible to do it that way?

Maybe it's possible but I don't think it's good to stall i915 removal. Also It's very easily to crash the kernel.
I've posted a sniped to the mailing list that tried to do that, the kernel still has crashed. Can you looked at?

> On the other hand, your last patch moves some part of the life cycle
> management into MTD core.
> The MTD will stay as long it has users.
> But that's only one part. The driver is still in charge to make sure that all
> operations fail immediately and that no new users arrive.

I think that case I would need to validate every HW access to make sure it's still valid.

> If we want to do all in MTD core we'd have to do it like SCSI disks.
> That means having devices states such as SDEV_RUNNING, SDEV_CANCEL,
> SDEV_OFFLINE, ....
> That way the MTD could be shutdown gracefully, first no new users are
> allowed, then ongoing operations will be cancelled, next all operation will fail
> with -EIO or such, then the device is being removed from sysfs and finally if
> the last user is gone, the MTD can be removed.

Isn't that already that way? You cannot open new handler. That I would need more of your insights.
> 
> I'm not sure whether we want to take that path.

Thanks
Tomas

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> 
> )On Tue, Feb 16, 2021 at 7:26 PM Tomas Winkler <tomas.winkler@intel.com>
> wrote:
> > Because the graphic card may undergo reset at any time and basically
> > hot unplug all its child devices, this series also provides a fix to
> > the mtd framework to make the reset graceful.
> 
> Well, just because MTD does not work as you expect, it is not broken. :-)
I'm not saying it's broken by design it just didn't fit this use case. 
> 
> In your case i915_spi_remove() blindly removes the MTD, this is not allowed.
> You may remove the MTD only if there are no more users.

I'm not sure it's good idea to stall the removal on user space.
This is just asking for a deadlock as user space is not getting what it needs and may stall
I think it's better the user space will fail gracefully the hw is not accessible in that stage anyway. 
> 
> The current model in MTD is that the driver is in charge of all life cycle
> management.
> Using ->_get_device() and ->_put_device() a driver can implement
> refcounting and deny new users if the MTD is about to disappear.

Please note that this use case you are describing is still valid, I haven't removed _get_device() _put_device() handlers,
You can still stall the removal of mtd, If this is not that way it's a bug

> 
> In the upcoming MUSE driver that mechanism is used too.
> MUSE allows to implement a MTD in userspace. So the FUSE server can
> disappear at
> *any* time. Just like in your case. Even worse, it can be hostile.
> In MUSE the MTD life time is tied to the FUSE connection object,
> muse_mtd_get_device()
> increments the FUSE connection refcount, and muse_mtd_put_device()
> decrements it.
> That means if the FUSE server disappears all of a sudden but the MTD still has
> users, the MTD will stay. But in this state no new references are allowed and
> all MTD operations of existing users will fail with -ENOTCONN (via FUSE).
> As soon the last user is gone (can be userspace via /dev/mtd* or a in-kernel
> user such as UBIFS), the MTD will be removed.

But in our case whole i915 is taken hostage, it cannot reset because of misbehaving user space.

> For the full details, please see:
> https://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git/tree/fs/fuse/m
> use.c?h=muse_v3#n1034
> 
> Is in your case *really* not possible to do it that way?

Maybe it's possible but I don't think it's good to stall i915 removal. Also It's very easily to crash the kernel.
I've posted a sniped to the mailing list that tried to do that, the kernel still has crashed. Can you looked at?

> On the other hand, your last patch moves some part of the life cycle
> management into MTD core.
> The MTD will stay as long it has users.
> But that's only one part. The driver is still in charge to make sure that all
> operations fail immediately and that no new users arrive.

I think that case I would need to validate every HW access to make sure it's still valid.

> If we want to do all in MTD core we'd have to do it like SCSI disks.
> That means having devices states such as SDEV_RUNNING, SDEV_CANCEL,
> SDEV_OFFLINE, ....
> That way the MTD could be shutdown gracefully, first no new users are
> allowed, then ongoing operations will be cancelled, next all operation will fail
> with -EIO or such, then the device is being removed from sysfs and finally if
> the last user is gone, the MTD can be removed.

Isn't that already that way? You cannot open new handler. That I would need more of your insights.
> 
> I'm not sure whether we want to take that path.

Thanks
Tomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> 
> 
> >
> > )On Tue, Feb 16, 2021 at 7:26 PM Tomas Winkler
> > <tomas.winkler@intel.com>
> > wrote:
> > > Because the graphic card may undergo reset at any time and basically
> > > hot unplug all its child devices, this series also provides a fix to
> > > the mtd framework to make the reset graceful.
> >
> > Well, just because MTD does not work as you expect, it is not broken.
> > :-)
> I'm not saying it's broken by design it just didn't fit this use case.
> >
> > In your case i915_spi_remove() blindly removes the MTD, this is not
> allowed.
> > You may remove the MTD only if there are no more users.
> 
> I'm not sure it's good idea to stall the removal on user space.
> This is just asking for a deadlock as user space is not getting what it needs and
> may stall I think it's better the user space will fail gracefully the hw is not
> accessible in that stage anyway.
> >
> > The current model in MTD is that the driver is in charge of all life
> > cycle management.
> > Using ->_get_device() and ->_put_device() a driver can implement
> > refcounting and deny new users if the MTD is about to disappear.
> 
> Please note that this use case you are describing is still valid, I haven't
> removed _get_device() _put_device() handlers, You can still stall the
> removal of mtd, If this is not that way it's a bug
> 
> >
> > In the upcoming MUSE driver that mechanism is used too.
> > MUSE allows to implement a MTD in userspace. So the FUSE server can
> > disappear at
> > *any* time. Just like in your case. Even worse, it can be hostile.
> > In MUSE the MTD life time is tied to the FUSE connection object,
> > muse_mtd_get_device()
> > increments the FUSE connection refcount, and muse_mtd_put_device()
> > decrements it.
> > That means if the FUSE server disappears all of a sudden but the MTD
> > still has users, the MTD will stay. But in this state no new
> > references are allowed and all MTD operations of existing users will fail
> with -ENOTCONN (via FUSE).
> > As soon the last user is gone (can be userspace via /dev/mtd* or a
> > in-kernel user such as UBIFS), the MTD will be removed.
> 
> But in our case whole i915 is taken hostage, it cannot reset because of
> misbehaving user space.
> 
> > For the full details, please see:
> > https://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git/tree/fs/fu
> > se/m
> > use.c?h=muse_v3#n1034
> >
> > Is in your case *really* not possible to do it that way?
> 
> Maybe it's possible but I don't think it's good to stall i915 removal. Also It's
> very easily to crash the kernel.
> I've posted a sniped to the mailing list that tried to do that, the kernel still has
> crashed. Can you looked at?
> 
> > On the other hand, your last patch moves some part of the life cycle
> > management into MTD core.
> > The MTD will stay as long it has users.
> > But that's only one part. The driver is still in charge to make sure
> > that all operations fail immediately and that no new users arrive.
> 
> I think that case I would need to validate every HW access to make sure it's
> still valid.
> 
> > If we want to do all in MTD core we'd have to do it like SCSI disks.
> > That means having devices states such as SDEV_RUNNING, SDEV_CANCEL,
> > SDEV_OFFLINE, ....
> > That way the MTD could be shutdown gracefully, first no new users are
> > allowed, then ongoing operations will be cancelled, next all operation
> > will fail with -EIO or such, then the device is being removed from
> > sysfs and finally if the last user is gone, the MTD can be removed.
> 
> Isn't that already that way? You cannot open new handler. That I would need
> more of your insights.
> >
> > I'm not sure whether we want to take that path.

Hi Richard is there any way we can try to unclutter this ?

Thanks
Tomas

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> 
> 
> >
> > )On Tue, Feb 16, 2021 at 7:26 PM Tomas Winkler
> > <tomas.winkler@intel.com>
> > wrote:
> > > Because the graphic card may undergo reset at any time and basically
> > > hot unplug all its child devices, this series also provides a fix to
> > > the mtd framework to make the reset graceful.
> >
> > Well, just because MTD does not work as you expect, it is not broken.
> > :-)
> I'm not saying it's broken by design it just didn't fit this use case.
> >
> > In your case i915_spi_remove() blindly removes the MTD, this is not
> allowed.
> > You may remove the MTD only if there are no more users.
> 
> I'm not sure it's good idea to stall the removal on user space.
> This is just asking for a deadlock as user space is not getting what it needs and
> may stall I think it's better the user space will fail gracefully the hw is not
> accessible in that stage anyway.
> >
> > The current model in MTD is that the driver is in charge of all life
> > cycle management.
> > Using ->_get_device() and ->_put_device() a driver can implement
> > refcounting and deny new users if the MTD is about to disappear.
> 
> Please note that this use case you are describing is still valid, I haven't
> removed _get_device() _put_device() handlers, You can still stall the
> removal of mtd, If this is not that way it's a bug
> 
> >
> > In the upcoming MUSE driver that mechanism is used too.
> > MUSE allows to implement a MTD in userspace. So the FUSE server can
> > disappear at
> > *any* time. Just like in your case. Even worse, it can be hostile.
> > In MUSE the MTD life time is tied to the FUSE connection object,
> > muse_mtd_get_device()
> > increments the FUSE connection refcount, and muse_mtd_put_device()
> > decrements it.
> > That means if the FUSE server disappears all of a sudden but the MTD
> > still has users, the MTD will stay. But in this state no new
> > references are allowed and all MTD operations of existing users will fail
> with -ENOTCONN (via FUSE).
> > As soon the last user is gone (can be userspace via /dev/mtd* or a
> > in-kernel user such as UBIFS), the MTD will be removed.
> 
> But in our case whole i915 is taken hostage, it cannot reset because of
> misbehaving user space.
> 
> > For the full details, please see:
> > https://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git/tree/fs/fu
> > se/m
> > use.c?h=muse_v3#n1034
> >
> > Is in your case *really* not possible to do it that way?
> 
> Maybe it's possible but I don't think it's good to stall i915 removal. Also It's
> very easily to crash the kernel.
> I've posted a sniped to the mailing list that tried to do that, the kernel still has
> crashed. Can you looked at?
> 
> > On the other hand, your last patch moves some part of the life cycle
> > management into MTD core.
> > The MTD will stay as long it has users.
> > But that's only one part. The driver is still in charge to make sure
> > that all operations fail immediately and that no new users arrive.
> 
> I think that case I would need to validate every HW access to make sure it's
> still valid.
> 
> > If we want to do all in MTD core we'd have to do it like SCSI disks.
> > That means having devices states such as SDEV_RUNNING, SDEV_CANCEL,
> > SDEV_OFFLINE, ....
> > That way the MTD could be shutdown gracefully, first no new users are
> > allowed, then ongoing operations will be cancelled, next all operation
> > will fail with -EIO or such, then the device is being removed from
> > sysfs and finally if the last user is gone, the MTD can be removed.
> 
> Isn't that already that way? You cannot open new handler. That I would need
> more of your insights.
> >
> > I'm not sure whether we want to take that path.

Hi Richard is there any way we can try to unclutter this ?

Thanks
Tomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Richard Weinberger]

----- Ursprüngliche Mail -----
>> > I'm not sure whether we want to take that path.
> 
> Hi Richard is there any way we can try to unclutter this ?

Of course there is a way. :-)
Your use-case really seems to be special and MTD needs an improvement.
Miquel, Vignesh and I just need to check more internals and corner cases in MTD.
With some luck your patch can be used as-is with some minor adjustments on top.

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Richard Weinberger]

----- Ursprüngliche Mail -----
>> > I'm not sure whether we want to take that path.
> 
> Hi Richard is there any way we can try to unclutter this ?

Of course there is a way. :-)
Your use-case really seems to be special and MTD needs an improvement.
Miquel, Vignesh and I just need to check more internals and corner cases in MTD.
With some luck your patch can be used as-is with some minor adjustments on top.

Thanks,
//richard
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> ----- Ursprüngliche Mail -----
> >> > I'm not sure whether we want to take that path.
> >
> > Hi Richard is there any way we can try to unclutter this ?
> 
> Of course there is a way. :-)
> Your use-case really seems to be special and MTD needs an improvement.
> Miquel, Vignesh and I just need to check more internals and corner cases in
> MTD.
> With some luck your patch can be used as-is with some minor adjustments
> on top.
Great, waiting for your comments. 
Thanks
Tomas

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> ----- Ursprüngliche Mail -----
> >> > I'm not sure whether we want to take that path.
> >
> > Hi Richard is there any way we can try to unclutter this ?
> 
> Of course there is a way. :-)
> Your use-case really seems to be special and MTD needs an improvement.
> Miquel, Vignesh and I just need to check more internals and corner cases in
> MTD.
> With some luck your patch can be used as-is with some minor adjustments
> on top.
Great, waiting for your comments. 
Thanks
Tomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> 
> 
> > ----- Ursprüngliche Mail -----
> > >> > I'm not sure whether we want to take that path.
> > >
> > > Hi Richard is there any way we can try to unclutter this ?
> >
> > Of course there is a way. :-)
> > Your use-case really seems to be special and MTD needs an improvement.
> > Miquel, Vignesh and I just need to check more internals and corner
> > cases in MTD.
> > With some luck your patch can be used as-is with some minor
> > adjustments on top.
> Great, waiting for your comments.

Hi,  I would like to send out the second version of the series. 
Please if you have any comments let me know.

Thanks
Tomas

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> 
> 
> > ----- Ursprüngliche Mail -----
> > >> > I'm not sure whether we want to take that path.
> > >
> > > Hi Richard is there any way we can try to unclutter this ?
> >
> > Of course there is a way. :-)
> > Your use-case really seems to be special and MTD needs an improvement.
> > Miquel, Vignesh and I just need to check more internals and corner
> > cases in MTD.
> > With some luck your patch can be used as-is with some minor
> > adjustments on top.
> Great, waiting for your comments.

Hi,  I would like to send out the second version of the series. 
Please if you have any comments let me know.

Thanks
Tomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Jani Nikula]

On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> Intel discrete graphic devices have internal spi storage, that holds
> firmware and oprom images. The spi device is exposed to the user space
> via mtd framework to be accessed during manufacturing.
> The device is hardware locked after manufacturing and only read access
> is provided.
>
> The i915 plays role of a multi function device (mfd) and spi device
> is exposed as its child device. i915_spi platform driver binds to 
> this device.

What's the plan wrt i915/spi maintainership?

BR,
Jani.

>
> Because the graphic card may undergo reset at any time and basically hot
> unplug all its child devices, this series also provides a fix to the mtd
> framework to make the reset graceful.
>
> Tomas Winkler (9):
>   drm/i915/spi: add spi device for discrete graphics
>   drm/i915/spi: intel_spi_region map
>   drm/i915/spi: add driver for on-die spi device
>   drm/i915/spi: implement region enumeration
>   drm/i915/spi: implement spi access functions
>   drm/i915/spi: spi register with mtd
>   drm/i915/spi: mtd: implement access handlers
>   drm/i915/spi: serialize spi access
>   mtd: use refcount to prevent corruption
>
>  drivers/gpu/drm/i915/Kconfig             |   3 +
>  drivers/gpu/drm/i915/Makefile            |   6 +
>  drivers/gpu/drm/i915/i915_drv.c          |   9 +
>  drivers/gpu/drm/i915/i915_drv.h          |   4 +
>  drivers/gpu/drm/i915/i915_reg.h          |   1 +
>  drivers/gpu/drm/i915/spi/intel_spi.c     |  62 +++
>  drivers/gpu/drm/i915/spi/intel_spi.h     |  24 +
>  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 675 +++++++++++++++++++++++
>  drivers/mtd/mtdcore.c                    |  63 ++-
>  drivers/mtd/mtdcore.h                    |   1 +
>  drivers/mtd/mtdpart.c                    |  13 +-
>  include/linux/mtd/mtd.h                  |   2 +-
>  12 files changed, 831 insertions(+), 32 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c

-- 
Jani Nikula, Intel Open Source Graphics Center

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Jani Nikula]

On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> Intel discrete graphic devices have internal spi storage, that holds
> firmware and oprom images. The spi device is exposed to the user space
> via mtd framework to be accessed during manufacturing.
> The device is hardware locked after manufacturing and only read access
> is provided.
>
> The i915 plays role of a multi function device (mfd) and spi device
> is exposed as its child device. i915_spi platform driver binds to 
> this device.

What's the plan wrt i915/spi maintainership?

BR,
Jani.

>
> Because the graphic card may undergo reset at any time and basically hot
> unplug all its child devices, this series also provides a fix to the mtd
> framework to make the reset graceful.
>
> Tomas Winkler (9):
>   drm/i915/spi: add spi device for discrete graphics
>   drm/i915/spi: intel_spi_region map
>   drm/i915/spi: add driver for on-die spi device
>   drm/i915/spi: implement region enumeration
>   drm/i915/spi: implement spi access functions
>   drm/i915/spi: spi register with mtd
>   drm/i915/spi: mtd: implement access handlers
>   drm/i915/spi: serialize spi access
>   mtd: use refcount to prevent corruption
>
>  drivers/gpu/drm/i915/Kconfig             |   3 +
>  drivers/gpu/drm/i915/Makefile            |   6 +
>  drivers/gpu/drm/i915/i915_drv.c          |   9 +
>  drivers/gpu/drm/i915/i915_drv.h          |   4 +
>  drivers/gpu/drm/i915/i915_reg.h          |   1 +
>  drivers/gpu/drm/i915/spi/intel_spi.c     |  62 +++
>  drivers/gpu/drm/i915/spi/intel_spi.h     |  24 +
>  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 675 +++++++++++++++++++++++
>  drivers/mtd/mtdcore.c                    |  63 ++-
>  drivers/mtd/mtdcore.h                    |   1 +
>  drivers/mtd/mtdpart.c                    |  13 +-
>  include/linux/mtd/mtd.h                  |   2 +-
>  12 files changed, 831 insertions(+), 32 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> 
> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> > Intel discrete graphic devices have internal spi storage, that holds
> > firmware and oprom images. The spi device is exposed to the user space
> > via mtd framework to be accessed during manufacturing.
> > The device is hardware locked after manufacturing and only read access
> > is provided.
> >
> > The i915 plays role of a multi function device (mfd) and spi device is
> > exposed as its child device. i915_spi platform driver binds to this
> > device.
> 
> What's the plan wrt i915/spi maintainership?

My suggestions is that this will be maintained by myself, as the major consumer is the manufacturing line.
It will be a separate section in MAINTAINERS file.

Thanks
Tomas



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> 
> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> > Intel discrete graphic devices have internal spi storage, that holds
> > firmware and oprom images. The spi device is exposed to the user space
> > via mtd framework to be accessed during manufacturing.
> > The device is hardware locked after manufacturing and only read access
> > is provided.
> >
> > The i915 plays role of a multi function device (mfd) and spi device is
> > exposed as its child device. i915_spi platform driver binds to this
> > device.
> 
> What's the plan wrt i915/spi maintainership?

My suggestions is that this will be maintained by myself, as the major consumer is the manufacturing line.
It will be a separate section in MAINTAINERS file.

Thanks
Tomas


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Jani Nikula]

On Wed, 17 Feb 2021, "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
>> 
>> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> > Intel discrete graphic devices have internal spi storage, that holds
>> > firmware and oprom images. The spi device is exposed to the user space
>> > via mtd framework to be accessed during manufacturing.
>> > The device is hardware locked after manufacturing and only read access
>> > is provided.
>> >
>> > The i915 plays role of a multi function device (mfd) and spi device is
>> > exposed as its child device. i915_spi platform driver binds to this
>> > device.
>> 
>> What's the plan wrt i915/spi maintainership?
>
> My suggestions is that this will be maintained by myself, as the major
> consumer is the manufacturing line.  It will be a separate section in
> MAINTAINERS file.

Works for me. Do you want to apply the patches directly to drm-intel, or
your own branch and send pull requests to i915 maintainers? Can also
start with the former, and move to the latter as needed.

Joonas, Rodrigo, thoughts?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Jani Nikula]

On Wed, 17 Feb 2021, "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
>> 
>> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> > Intel discrete graphic devices have internal spi storage, that holds
>> > firmware and oprom images. The spi device is exposed to the user space
>> > via mtd framework to be accessed during manufacturing.
>> > The device is hardware locked after manufacturing and only read access
>> > is provided.
>> >
>> > The i915 plays role of a multi function device (mfd) and spi device is
>> > exposed as its child device. i915_spi platform driver binds to this
>> > device.
>> 
>> What's the plan wrt i915/spi maintainership?
>
> My suggestions is that this will be maintained by myself, as the major
> consumer is the manufacturing line.  It will be a separate section in
> MAINTAINERS file.

Works for me. Do you want to apply the patches directly to drm-intel, or
your own branch and send pull requests to i915 maintainers? Can also
start with the former, and move to the latter as needed.

Joonas, Rodrigo, thoughts?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Rodrigo Vivi]

On Wed, Feb 17, 2021 at 03:35:19PM +0200, Jani Nikula wrote:
> On Wed, 17 Feb 2021, "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
> >> 
> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> >> > Intel discrete graphic devices have internal spi storage, that holds
> >> > firmware and oprom images. The spi device is exposed to the user space
> >> > via mtd framework to be accessed during manufacturing.
> >> > The device is hardware locked after manufacturing and only read access
> >> > is provided.
> >> >
> >> > The i915 plays role of a multi function device (mfd) and spi device is
> >> > exposed as its child device. i915_spi platform driver binds to this
> >> > device.
> >> 
> >> What's the plan wrt i915/spi maintainership?
> >
> > My suggestions is that this will be maintained by myself, as the major
> > consumer is the manufacturing line.  It will be a separate section in
> > MAINTAINERS file.
> 
> Works for me. Do you want to apply the patches directly to drm-intel, or
> your own branch and send pull requests to i915 maintainers? Can also
> start with the former, and move to the latter as needed.
> 
> Joonas, Rodrigo, thoughts?

No strong opinion here. But I believe the pull request flow makes sense.

> 
> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Rodrigo Vivi]

On Wed, Feb 17, 2021 at 03:35:19PM +0200, Jani Nikula wrote:
> On Wed, 17 Feb 2021, "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
> >> 
> >> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> >> > Intel discrete graphic devices have internal spi storage, that holds
> >> > firmware and oprom images. The spi device is exposed to the user space
> >> > via mtd framework to be accessed during manufacturing.
> >> > The device is hardware locked after manufacturing and only read access
> >> > is provided.
> >> >
> >> > The i915 plays role of a multi function device (mfd) and spi device is
> >> > exposed as its child device. i915_spi platform driver binds to this
> >> > device.
> >> 
> >> What's the plan wrt i915/spi maintainership?
> >
> > My suggestions is that this will be maintained by myself, as the major
> > consumer is the manufacturing line.  It will be a separate section in
> > MAINTAINERS file.
> 
> Works for me. Do you want to apply the patches directly to drm-intel, or
> your own branch and send pull requests to i915 maintainers? Can also
> start with the former, and move to the latter as needed.
> 
> Joonas, Rodrigo, thoughts?

No strong opinion here. But I believe the pull request flow makes sense.

> 
> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Jani Nikula]

On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> Intel discrete graphic devices have internal spi storage, that holds
> firmware and oprom images. The spi device is exposed to the user space
> via mtd framework to be accessed during manufacturing.
> The device is hardware locked after manufacturing and only read access
> is provided.
>
> The i915 plays role of a multi function device (mfd) and spi device
> is exposed as its child device. i915_spi platform driver binds to 
> this device.
>
> Because the graphic card may undergo reset at any time and basically hot
> unplug all its child devices, this series also provides a fix to the mtd
> framework to make the reset graceful.
>
> Tomas Winkler (9):
>   drm/i915/spi: add spi device for discrete graphics
>   drm/i915/spi: intel_spi_region map
>   drm/i915/spi: add driver for on-die spi device
>   drm/i915/spi: implement region enumeration
>   drm/i915/spi: implement spi access functions
>   drm/i915/spi: spi register with mtd
>   drm/i915/spi: mtd: implement access handlers
>   drm/i915/spi: serialize spi access
>   mtd: use refcount to prevent corruption
>
>  drivers/gpu/drm/i915/Kconfig             |   3 +
>  drivers/gpu/drm/i915/Makefile            |   6 +
>  drivers/gpu/drm/i915/i915_drv.c          |   9 +
>  drivers/gpu/drm/i915/i915_drv.h          |   4 +
>  drivers/gpu/drm/i915/i915_reg.h          |   1 +
>  drivers/gpu/drm/i915/spi/intel_spi.c     |  62 +++
>  drivers/gpu/drm/i915/spi/intel_spi.h     |  24 +

I'm open to discussion, but after glancing through the series I've got a
gut feeling spi/ subdir should be purely about the separate module, and
the above two files should be in i915/ directory instead.

As it is, I think it's a bit confusing that spi/ is both about the spi
kernel module and a singly .c file that's really part of
i915.ko. Perhaps that messes up the conventional descending to subdirs
in the kernel build too?

BR,
Jani.

>  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 675 +++++++++++++++++++++++
>  drivers/mtd/mtdcore.c                    |  63 ++-
>  drivers/mtd/mtdcore.h                    |   1 +
>  drivers/mtd/mtdpart.c                    |  13 +-
>  include/linux/mtd/mtd.h                  |   2 +-
>  12 files changed, 831 insertions(+), 32 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c

-- 
Jani Nikula, Intel Open Source Graphics Center

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Jani Nikula]

On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> Intel discrete graphic devices have internal spi storage, that holds
> firmware and oprom images. The spi device is exposed to the user space
> via mtd framework to be accessed during manufacturing.
> The device is hardware locked after manufacturing and only read access
> is provided.
>
> The i915 plays role of a multi function device (mfd) and spi device
> is exposed as its child device. i915_spi platform driver binds to 
> this device.
>
> Because the graphic card may undergo reset at any time and basically hot
> unplug all its child devices, this series also provides a fix to the mtd
> framework to make the reset graceful.
>
> Tomas Winkler (9):
>   drm/i915/spi: add spi device for discrete graphics
>   drm/i915/spi: intel_spi_region map
>   drm/i915/spi: add driver for on-die spi device
>   drm/i915/spi: implement region enumeration
>   drm/i915/spi: implement spi access functions
>   drm/i915/spi: spi register with mtd
>   drm/i915/spi: mtd: implement access handlers
>   drm/i915/spi: serialize spi access
>   mtd: use refcount to prevent corruption
>
>  drivers/gpu/drm/i915/Kconfig             |   3 +
>  drivers/gpu/drm/i915/Makefile            |   6 +
>  drivers/gpu/drm/i915/i915_drv.c          |   9 +
>  drivers/gpu/drm/i915/i915_drv.h          |   4 +
>  drivers/gpu/drm/i915/i915_reg.h          |   1 +
>  drivers/gpu/drm/i915/spi/intel_spi.c     |  62 +++
>  drivers/gpu/drm/i915/spi/intel_spi.h     |  24 +

I'm open to discussion, but after glancing through the series I've got a
gut feeling spi/ subdir should be purely about the separate module, and
the above two files should be in i915/ directory instead.

As it is, I think it's a bit confusing that spi/ is both about the spi
kernel module and a singly .c file that's really part of
i915.ko. Perhaps that messes up the conventional descending to subdirs
in the kernel build too?

BR,
Jani.

>  drivers/gpu/drm/i915/spi/intel_spi_drv.c | 675 +++++++++++++++++++++++
>  drivers/mtd/mtdcore.c                    |  63 ++-
>  drivers/mtd/mtdcore.h                    |   1 +
>  drivers/mtd/mtdpart.c                    |  13 +-
>  include/linux/mtd/mtd.h                  |   2 +-
>  12 files changed, 831 insertions(+), 32 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
>  create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> 
> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> > Intel discrete graphic devices have internal spi storage, that holds
> > firmware and oprom images. The spi device is exposed to the user space
> > via mtd framework to be accessed during manufacturing.
> > The device is hardware locked after manufacturing and only read access
> > is provided.
> >
> > The i915 plays role of a multi function device (mfd) and spi device is
> > exposed as its child device. i915_spi platform driver binds to this
> > device.
> >
> > Because the graphic card may undergo reset at any time and basically
> > hot unplug all its child devices, this series also provides a fix to
> > the mtd framework to make the reset graceful.
> >
> > Tomas Winkler (9):
> >   drm/i915/spi: add spi device for discrete graphics
> >   drm/i915/spi: intel_spi_region map
> >   drm/i915/spi: add driver for on-die spi device
> >   drm/i915/spi: implement region enumeration
> >   drm/i915/spi: implement spi access functions
> >   drm/i915/spi: spi register with mtd
> >   drm/i915/spi: mtd: implement access handlers
> >   drm/i915/spi: serialize spi access
> >   mtd: use refcount to prevent corruption
> >
> >  drivers/gpu/drm/i915/Kconfig             |   3 +
> >  drivers/gpu/drm/i915/Makefile            |   6 +
> >  drivers/gpu/drm/i915/i915_drv.c          |   9 +
> >  drivers/gpu/drm/i915/i915_drv.h          |   4 +
> >  drivers/gpu/drm/i915/i915_reg.h          |   1 +
> >  drivers/gpu/drm/i915/spi/intel_spi.c     |  62 +++
> >  drivers/gpu/drm/i915/spi/intel_spi.h     |  24 +
> 
> I'm open to discussion, but after glancing through the series I've got a gut
> feeling spi/ subdir should be purely about the separate module, and the
> above two files should be in i915/ directory instead.

Maybe, I don't have strong feelings about that, it is just a decision from which point you want to look at that.
> 
> As it is, I think it's a bit confusing that spi/ is both about the spi kernel module
> and a singly .c file that's really part of i915.ko. Perhaps that messes up the
> conventional descending to subdirs in the kernel build too?

The intention was to make this capsulated from the file system point of view. 
In general the spi driver could be somewhere in mtd directory, but it doesn't really fit exactly there either.
I don't have a strong opinion about that, if you do I yield. 


Thanks
Tomas


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Winkler, Tomas]

> 
> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
> > Intel discrete graphic devices have internal spi storage, that holds
> > firmware and oprom images. The spi device is exposed to the user space
> > via mtd framework to be accessed during manufacturing.
> > The device is hardware locked after manufacturing and only read access
> > is provided.
> >
> > The i915 plays role of a multi function device (mfd) and spi device is
> > exposed as its child device. i915_spi platform driver binds to this
> > device.
> >
> > Because the graphic card may undergo reset at any time and basically
> > hot unplug all its child devices, this series also provides a fix to
> > the mtd framework to make the reset graceful.
> >
> > Tomas Winkler (9):
> >   drm/i915/spi: add spi device for discrete graphics
> >   drm/i915/spi: intel_spi_region map
> >   drm/i915/spi: add driver for on-die spi device
> >   drm/i915/spi: implement region enumeration
> >   drm/i915/spi: implement spi access functions
> >   drm/i915/spi: spi register with mtd
> >   drm/i915/spi: mtd: implement access handlers
> >   drm/i915/spi: serialize spi access
> >   mtd: use refcount to prevent corruption
> >
> >  drivers/gpu/drm/i915/Kconfig             |   3 +
> >  drivers/gpu/drm/i915/Makefile            |   6 +
> >  drivers/gpu/drm/i915/i915_drv.c          |   9 +
> >  drivers/gpu/drm/i915/i915_drv.h          |   4 +
> >  drivers/gpu/drm/i915/i915_reg.h          |   1 +
> >  drivers/gpu/drm/i915/spi/intel_spi.c     |  62 +++
> >  drivers/gpu/drm/i915/spi/intel_spi.h     |  24 +
> 
> I'm open to discussion, but after glancing through the series I've got a gut
> feeling spi/ subdir should be purely about the separate module, and the
> above two files should be in i915/ directory instead.

Maybe, I don't have strong feelings about that, it is just a decision from which point you want to look at that.
> 
> As it is, I think it's a bit confusing that spi/ is both about the spi kernel module
> and a singly .c file that's really part of i915.ko. Perhaps that messes up the
> conventional descending to subdirs in the kernel build too?

The intention was to make this capsulated from the file system point of view. 
In general the spi driver could be somewhere in mtd directory, but it doesn't really fit exactly there either.
I don't have a strong opinion about that, if you do I yield. 


Thanks
Tomas

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Jani Nikula]

On Wed, 17 Feb 2021, "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
>> 
>> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> > Intel discrete graphic devices have internal spi storage, that holds
>> > firmware and oprom images. The spi device is exposed to the user space
>> > via mtd framework to be accessed during manufacturing.
>> > The device is hardware locked after manufacturing and only read access
>> > is provided.
>> >
>> > The i915 plays role of a multi function device (mfd) and spi device is
>> > exposed as its child device. i915_spi platform driver binds to this
>> > device.
>> >
>> > Because the graphic card may undergo reset at any time and basically
>> > hot unplug all its child devices, this series also provides a fix to
>> > the mtd framework to make the reset graceful.
>> >
>> > Tomas Winkler (9):
>> >   drm/i915/spi: add spi device for discrete graphics
>> >   drm/i915/spi: intel_spi_region map
>> >   drm/i915/spi: add driver for on-die spi device
>> >   drm/i915/spi: implement region enumeration
>> >   drm/i915/spi: implement spi access functions
>> >   drm/i915/spi: spi register with mtd
>> >   drm/i915/spi: mtd: implement access handlers
>> >   drm/i915/spi: serialize spi access
>> >   mtd: use refcount to prevent corruption
>> >
>> >  drivers/gpu/drm/i915/Kconfig             |   3 +
>> >  drivers/gpu/drm/i915/Makefile            |   6 +
>> >  drivers/gpu/drm/i915/i915_drv.c          |   9 +
>> >  drivers/gpu/drm/i915/i915_drv.h          |   4 +
>> >  drivers/gpu/drm/i915/i915_reg.h          |   1 +
>> >  drivers/gpu/drm/i915/spi/intel_spi.c     |  62 +++
>> >  drivers/gpu/drm/i915/spi/intel_spi.h     |  24 +
>> 
>> I'm open to discussion, but after glancing through the series I've got a gut
>> feeling spi/ subdir should be purely about the separate module, and the
>> above two files should be in i915/ directory instead.
>
> Maybe, I don't have strong feelings about that, it is just a decision from which point you want to look at that.

*shrug*

No strong feelings either, and I don't think the decision is carved in
stone. We can move them around later if we want.

Up to you.

BR,
Jani.


>> 
>> As it is, I think it's a bit confusing that spi/ is both about the spi kernel module
>> and a singly .c file that's really part of i915.ko. Perhaps that messes up the
>> conventional descending to subdirs in the kernel build too?
>
> The intention was to make this capsulated from the file system point of view. 
> In general the spi driver could be somewhere in mtd directory, but it doesn't really fit exactly there either.
> I don't have a strong opinion about that, if you do I yield. 
>
>
> Thanks
> Tomas
>

-- 
Jani Nikula, Intel Open Source Graphics Center

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi

[Jani Nikula]

On Wed, 17 Feb 2021, "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
>> 
>> On Tue, 16 Feb 2021, Tomas Winkler <tomas.winkler@intel.com> wrote:
>> > Intel discrete graphic devices have internal spi storage, that holds
>> > firmware and oprom images. The spi device is exposed to the user space
>> > via mtd framework to be accessed during manufacturing.
>> > The device is hardware locked after manufacturing and only read access
>> > is provided.
>> >
>> > The i915 plays role of a multi function device (mfd) and spi device is
>> > exposed as its child device. i915_spi platform driver binds to this
>> > device.
>> >
>> > Because the graphic card may undergo reset at any time and basically
>> > hot unplug all its child devices, this series also provides a fix to
>> > the mtd framework to make the reset graceful.
>> >
>> > Tomas Winkler (9):
>> >   drm/i915/spi: add spi device for discrete graphics
>> >   drm/i915/spi: intel_spi_region map
>> >   drm/i915/spi: add driver for on-die spi device
>> >   drm/i915/spi: implement region enumeration
>> >   drm/i915/spi: implement spi access functions
>> >   drm/i915/spi: spi register with mtd
>> >   drm/i915/spi: mtd: implement access handlers
>> >   drm/i915/spi: serialize spi access
>> >   mtd: use refcount to prevent corruption
>> >
>> >  drivers/gpu/drm/i915/Kconfig             |   3 +
>> >  drivers/gpu/drm/i915/Makefile            |   6 +
>> >  drivers/gpu/drm/i915/i915_drv.c          |   9 +
>> >  drivers/gpu/drm/i915/i915_drv.h          |   4 +
>> >  drivers/gpu/drm/i915/i915_reg.h          |   1 +
>> >  drivers/gpu/drm/i915/spi/intel_spi.c     |  62 +++
>> >  drivers/gpu/drm/i915/spi/intel_spi.h     |  24 +
>> 
>> I'm open to discussion, but after glancing through the series I've got a gut
>> feeling spi/ subdir should be purely about the separate module, and the
>> above two files should be in i915/ directory instead.
>
> Maybe, I don't have strong feelings about that, it is just a decision from which point you want to look at that.

*shrug*

No strong feelings either, and I don't think the decision is carved in
stone. We can move them around later if we want.

Up to you.

BR,
Jani.


>> 
>> As it is, I think it's a bit confusing that spi/ is both about the spi kernel module
>> and a singly .c file that's really part of i915.ko. Perhaps that messes up the
>> conventional descending to subdirs in the kernel build too?
>
> The intention was to make this capsulated from the file system point of view. 
> In general the spi driver could be somewhere in mtd directory, but it doesn't really fit exactly there either.
> I don't have a strong opinion about that, if you do I yield. 
>
>
> Thanks
> Tomas
>

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx