[PATCH v3 0/5] Introduce Intel Elkhart Lake PSE TIO

[PATCH v3 0/5] Introduce Intel Elkhart Lake PSE TIO

[Raag Jadav]

Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
devices that expose two different capabilities of GPIO and Timed I/O
as a single PCI function through shared MMIO.

This series adds MFD driver for them and extends PPS generator driver
to support initial PSE TIO functionality.

v2: Use consistent naming with Intel drivers (Andy)
    Add MFD dependency for leaf drivers (Andy)
    Aesthetic adjustments (Andy)
    Update tags

v3: Use consistent naming in MAINTAINERS entry (Andy)
    Use COMPILE_TEST in a practical (all or nothing) way (Andy)

Raag Jadav (5):
  mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO
  gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO
  pps: generators: tio: split pps_gen_tio.h
  pps: generators: tio: move to match_data() model
  pps: generators: tio: Introduce Intel Elkhart Lake PSE TIO

 MAINTAINERS                          |   5 ++
 drivers/gpio/Kconfig                 |   2 +-
 drivers/mfd/Kconfig                  |  12 ++++
 drivers/mfd/Makefile                 |   1 +
 drivers/mfd/intel_ehl_pse_gpio.c     | 100 +++++++++++++++++++++++++++
 drivers/pps/generators/Kconfig       |   2 +-
 drivers/pps/generators/pps_gen_tio.c |  80 ++++++++++-----------
 drivers/pps/generators/pps_gen_tio.h |  67 ++++++++++++++++++
 8 files changed, 228 insertions(+), 41 deletions(-)
 create mode 100644 drivers/mfd/intel_ehl_pse_gpio.c
 create mode 100644 drivers/pps/generators/pps_gen_tio.h


base-commit: 264ff8415aed324584acc85740596f6e1df7b663
-- 
2.34.1

[PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Raag Jadav]

Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
devices that expose two different capabilities of GPIO and Timed I/O
as a single PCI function through shared MMIO.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 MAINTAINERS                      |   5 ++
 drivers/mfd/Kconfig              |  12 ++++
 drivers/mfd/Makefile             |   1 +
 drivers/mfd/intel_ehl_pse_gpio.c | 100 +++++++++++++++++++++++++++++++
 4 files changed, 118 insertions(+)
 create mode 100644 drivers/mfd/intel_ehl_pse_gpio.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d4280facbe51..eb216eebb3a6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11604,6 +11604,11 @@ F:	drivers/gpu/drm/xe/
 F:	include/drm/intel/
 F:	include/uapi/drm/xe_drm.h
 
+INTEL EHL PSE GPIO MFD DRIVER
+M:	Raag Jadav <raag.jadav@intel.com>
+S:	Supported
+F:	drivers/mfd/intel_ehl_pse_gpio.c
+
 INTEL ETHERNET DRIVERS
 M:	Tony Nguyen <anthony.l.nguyen@intel.com>
 M:	Przemek Kitszel <przemyslaw.kitszel@intel.com>
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6b0682af6e32..36eac5245179 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -597,6 +597,18 @@ config MFD_HI655X_PMIC
 	help
 	  Select this option to enable Hisilicon hi655x series pmic driver.
 
+config MFD_INTEL_EHL_PSE_GPIO
+	tristate "Intel Elkhart Lake PSE GPIO MFD"
+	depends on PCI && (X86 || COMPILE_TEST)
+	select MFD_CORE
+	help
+	  This MFD provides support for GPIO and TIO that exist on Intel
+	  Elkhart Lake PSE as a single PCI device. It splits the two I/O
+	  devices to their respective I/O drivers.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called intel_ehl_pse_gpio.
+
 config MFD_INTEL_QUARK_I2C_GPIO
 	tristate "Intel Quark MFD I2C GPIO"
 	depends on PCI
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9220eaf7cf12..8f7d257856db 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -196,6 +196,7 @@ obj-$(CONFIG_MFD_TIMBERDALE)    += timberdale.o
 obj-$(CONFIG_PMIC_ADP5520)	+= adp5520.o
 obj-$(CONFIG_MFD_ADP5585)	+= adp5585.o
 obj-$(CONFIG_MFD_KEMPLD)	+= kempld-core.o
+obj-$(CONFIG_MFD_INTEL_EHL_PSE_GPIO)	+= intel_ehl_pse_gpio.o
 obj-$(CONFIG_MFD_INTEL_QUARK_I2C_GPIO)	+= intel_quark_i2c_gpio.o
 obj-$(CONFIG_LPC_SCH)		+= lpc_sch.o
 obj-$(CONFIG_LPC_ICH)		+= lpc_ich.o
diff --git a/drivers/mfd/intel_ehl_pse_gpio.c b/drivers/mfd/intel_ehl_pse_gpio.c
new file mode 100644
index 000000000000..6a6ad1390a7b
--- /dev/null
+++ b/drivers/mfd/intel_ehl_pse_gpio.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel MFD driver for Elkhart Lake - Programmable Service Engine
+ * (PSE) GPIO & TIO
+ *
+ * Copyright (c) 2025 Intel Corporation
+ *
+ * Intel Elkhart Lake PSE includes two PCI devices that expose two
+ * different capabilities of GPIO and Timed I/O as a single PCI
+ * function through shared MMIO.
+ */
+
+#include <linux/array_size.h>
+#include <linux/ioport.h>
+#include <linux/mfd/core.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/stddef.h>
+
+#define PSE_GPIO_OFFSET		0x0000
+#define PSE_GPIO_SIZE		0x0134
+
+#define PSE_TIO_OFFSET		0x1000
+#define PSE_TIO_SIZE		0x06B0
+
+static struct resource ehl_pse_gpio_resources[] = {
+	DEFINE_RES_MEM(PSE_GPIO_OFFSET, PSE_GPIO_SIZE),
+	DEFINE_RES_IRQ(0),
+};
+
+static struct resource ehl_pse_tio_resources[] = {
+	DEFINE_RES_MEM(PSE_TIO_OFFSET, PSE_TIO_SIZE),
+	DEFINE_RES_IRQ(1),
+};
+
+static struct mfd_cell ehl_pse_gpio_devs[] = {
+	{
+		.name = "gpio-elkhartlake",
+		.num_resources = ARRAY_SIZE(ehl_pse_gpio_resources),
+		.resources = ehl_pse_gpio_resources,
+		.ignore_resource_conflicts = true,
+	},
+	{
+		.name = "pps-gen-tio",
+		.num_resources = ARRAY_SIZE(ehl_pse_tio_resources),
+		.resources = ehl_pse_tio_resources,
+		.ignore_resource_conflicts = true,
+	},
+};
+
+static int ehl_pse_gpio_probe(struct pci_dev *pci, const struct pci_device_id *id)
+{
+	int ret;
+
+	ret = pcim_enable_device(pci);
+	if (ret)
+		return ret;
+
+	pci_set_master(pci);
+
+	ret = pci_alloc_irq_vectors(pci, 2, 2, PCI_IRQ_ALL_TYPES);
+	if (ret < 0)
+		return ret;
+
+	ret = mfd_add_devices(&pci->dev, PLATFORM_DEVID_AUTO, ehl_pse_gpio_devs,
+			      ARRAY_SIZE(ehl_pse_gpio_devs), pci_resource_n(pci, 0),
+			      pci_irq_vector(pci, 0), NULL);
+	if (ret)
+		pci_free_irq_vectors(pci);
+
+	return ret;
+}
+
+static void ehl_pse_gpio_remove(struct pci_dev *pdev)
+{
+	mfd_remove_devices(&pdev->dev);
+	pci_free_irq_vectors(pdev);
+}
+
+static const struct pci_device_id ehl_pse_gpio_ids[] = {
+	{ PCI_VDEVICE(INTEL, 0x4b88) },
+	{ PCI_VDEVICE(INTEL, 0x4b89) },
+	{}
+};
+MODULE_DEVICE_TABLE(pci, ehl_pse_gpio_ids);
+
+static struct pci_driver ehl_pse_gpio_driver = {
+	.probe		= ehl_pse_gpio_probe,
+	.remove		= ehl_pse_gpio_remove,
+	.id_table	= ehl_pse_gpio_ids,
+	.name		= "ehl_pse_gpio",
+};
+module_pci_driver(ehl_pse_gpio_driver);
+
+MODULE_AUTHOR("Raymond Tan <raymond.tan@intel.com>");
+MODULE_AUTHOR("Raag Jadav <raag.jadav@intel.com>");
+MODULE_DESCRIPTION("Intel MFD for Elkhart Lake PSE GPIO & TIO");
+MODULE_LICENSE("GPL");
-- 
2.34.1

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Lee Jones]

On Fri, 07 Mar 2025, Raag Jadav wrote:

> Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
> devices that expose two different capabilities of GPIO and Timed I/O
> as a single PCI function through shared MMIO.
> 
> Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  MAINTAINERS                      |   5 ++
>  drivers/mfd/Kconfig              |  12 ++++
>  drivers/mfd/Makefile             |   1 +
>  drivers/mfd/intel_ehl_pse_gpio.c | 100 +++++++++++++++++++++++++++++++
>  4 files changed, 118 insertions(+)
>  create mode 100644 drivers/mfd/intel_ehl_pse_gpio.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d4280facbe51..eb216eebb3a6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11604,6 +11604,11 @@ F:	drivers/gpu/drm/xe/
>  F:	include/drm/intel/
>  F:	include/uapi/drm/xe_drm.h
>  
> +INTEL EHL PSE GPIO MFD DRIVER
> +M:	Raag Jadav <raag.jadav@intel.com>
> +S:	Supported
> +F:	drivers/mfd/intel_ehl_pse_gpio.c
> +
>  INTEL ETHERNET DRIVERS
>  M:	Tony Nguyen <anthony.l.nguyen@intel.com>
>  M:	Przemek Kitszel <przemyslaw.kitszel@intel.com>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 6b0682af6e32..36eac5245179 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -597,6 +597,18 @@ config MFD_HI655X_PMIC
>  	help
>  	  Select this option to enable Hisilicon hi655x series pmic driver.
>  
> +config MFD_INTEL_EHL_PSE_GPIO
> +	tristate "Intel Elkhart Lake PSE GPIO MFD"
> +	depends on PCI && (X86 || COMPILE_TEST)
> +	select MFD_CORE
> +	help
> +	  This MFD provides support for GPIO and TIO that exist on Intel

Remove references to MFD.

> +	  Elkhart Lake PSE as a single PCI device. It splits the two I/O
> +	  devices to their respective I/O drivers.
> +
> +	  To compile this driver as a module, choose M here: the module will
> +	  be called intel_ehl_pse_gpio.
> +
>  config MFD_INTEL_QUARK_I2C_GPIO
>  	tristate "Intel Quark MFD I2C GPIO"
>  	depends on PCI
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9220eaf7cf12..8f7d257856db 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -196,6 +196,7 @@ obj-$(CONFIG_MFD_TIMBERDALE)    += timberdale.o
>  obj-$(CONFIG_PMIC_ADP5520)	+= adp5520.o
>  obj-$(CONFIG_MFD_ADP5585)	+= adp5585.o
>  obj-$(CONFIG_MFD_KEMPLD)	+= kempld-core.o
> +obj-$(CONFIG_MFD_INTEL_EHL_PSE_GPIO)	+= intel_ehl_pse_gpio.o
>  obj-$(CONFIG_MFD_INTEL_QUARK_I2C_GPIO)	+= intel_quark_i2c_gpio.o
>  obj-$(CONFIG_LPC_SCH)		+= lpc_sch.o
>  obj-$(CONFIG_LPC_ICH)		+= lpc_ich.o
> diff --git a/drivers/mfd/intel_ehl_pse_gpio.c b/drivers/mfd/intel_ehl_pse_gpio.c
> new file mode 100644
> index 000000000000..6a6ad1390a7b
> --- /dev/null
> +++ b/drivers/mfd/intel_ehl_pse_gpio.c
> @@ -0,0 +1,100 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Intel MFD driver for Elkhart Lake - Programmable Service Engine

As above.

> + * (PSE) GPIO & TIO
> + *
> + * Copyright (c) 2025 Intel Corporation
> + *
> + * Intel Elkhart Lake PSE includes two PCI devices that expose two
> + * different capabilities of GPIO and Timed I/O as a single PCI
> + * function through shared MMIO.
> + */
> +
> +#include <linux/array_size.h>
> +#include <linux/ioport.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/stddef.h>
> +
> +#define PSE_GPIO_OFFSET		0x0000
> +#define PSE_GPIO_SIZE		0x0134
> +
> +#define PSE_TIO_OFFSET		0x1000
> +#define PSE_TIO_SIZE		0x06B0
> +
> +static struct resource ehl_pse_gpio_resources[] = {
> +	DEFINE_RES_MEM(PSE_GPIO_OFFSET, PSE_GPIO_SIZE),
> +	DEFINE_RES_IRQ(0),
> +};
> +
> +static struct resource ehl_pse_tio_resources[] = {
> +	DEFINE_RES_MEM(PSE_TIO_OFFSET, PSE_TIO_SIZE),
> +	DEFINE_RES_IRQ(1),
> +};
> +
> +static struct mfd_cell ehl_pse_gpio_devs[] = {
> +	{
> +		.name = "gpio-elkhartlake",
> +		.num_resources = ARRAY_SIZE(ehl_pse_gpio_resources),
> +		.resources = ehl_pse_gpio_resources,
> +		.ignore_resource_conflicts = true,
> +	},
> +	{
> +		.name = "pps-gen-tio",
> +		.num_resources = ARRAY_SIZE(ehl_pse_tio_resources),
> +		.resources = ehl_pse_tio_resources,
> +		.ignore_resource_conflicts = true,
> +	},
> +};
> +
> +static int ehl_pse_gpio_probe(struct pci_dev *pci, const struct pci_device_id *id)
> +{
> +	int ret;
> +
> +	ret = pcim_enable_device(pci);
> +	if (ret)
> +		return ret;
> +
> +	pci_set_master(pci);
> +
> +	ret = pci_alloc_irq_vectors(pci, 2, 2, PCI_IRQ_ALL_TYPES);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = mfd_add_devices(&pci->dev, PLATFORM_DEVID_AUTO, ehl_pse_gpio_devs,

dev_*?

> +			      ARRAY_SIZE(ehl_pse_gpio_devs), pci_resource_n(pci, 0),
> +			      pci_irq_vector(pci, 0), NULL);
> +	if (ret)
> +		pci_free_irq_vectors(pci);
> +
> +	return ret;
> +}
> +
> +static void ehl_pse_gpio_remove(struct pci_dev *pdev)
> +{
> +	mfd_remove_devices(&pdev->dev);
> +	pci_free_irq_vectors(pdev);
> +}
> +
> +static const struct pci_device_id ehl_pse_gpio_ids[] = {
> +	{ PCI_VDEVICE(INTEL, 0x4b88) },
> +	{ PCI_VDEVICE(INTEL, 0x4b89) },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(pci, ehl_pse_gpio_ids);
> +
> +static struct pci_driver ehl_pse_gpio_driver = {
> +	.probe		= ehl_pse_gpio_probe,
> +	.remove		= ehl_pse_gpio_remove,
> +	.id_table	= ehl_pse_gpio_ids,
> +	.name		= "ehl_pse_gpio",
> +};
> +module_pci_driver(ehl_pse_gpio_driver);
> +
> +MODULE_AUTHOR("Raymond Tan <raymond.tan@intel.com>");
> +MODULE_AUTHOR("Raag Jadav <raag.jadav@intel.com>");
> +MODULE_DESCRIPTION("Intel MFD for Elkhart Lake PSE GPIO & TIO");
> +MODULE_LICENSE("GPL");
> -- 
> 2.34.1
> 

-- 
Lee Jones [李琼斯]

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Andy Shevchenko]

On Fri, Mar 14, 2025 at 12:44:50PM +0000, Lee Jones wrote:
> On Fri, 07 Mar 2025, Raag Jadav wrote:
> 
> > Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
> > devices that expose two different capabilities of GPIO and Timed I/O
> > as a single PCI function through shared MMIO.

...

> > +	ret = pci_alloc_irq_vectors(pci, 2, 2, PCI_IRQ_ALL_TYPES);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = mfd_add_devices(&pci->dev, PLATFORM_DEVID_AUTO, ehl_pse_gpio_devs,
> 
> dev_*?

devm_* ?


> > +			      ARRAY_SIZE(ehl_pse_gpio_devs), pci_resource_n(pci, 0),
> > +			      pci_irq_vector(pci, 0), NULL);
> > +	if (ret)
> > +		pci_free_irq_vectors(pci);

Anyway, the choice as far as I understood it is motivated by usage of
pci_*_irq_vector() APIs, which are officially not manageable (however
in practice they are).

> > +	return ret;
> > +}
> > +
> > +static void ehl_pse_gpio_remove(struct pci_dev *pdev)
> > +{
> > +	mfd_remove_devices(&pdev->dev);
> > +	pci_free_irq_vectors(pdev);
> > +}

Same here.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Lee Jones]

On Fri, 14 Mar 2025, Andy Shevchenko wrote:

> On Fri, Mar 14, 2025 at 12:44:50PM +0000, Lee Jones wrote:
> > On Fri, 07 Mar 2025, Raag Jadav wrote:
> > 
> > > Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
> > > devices that expose two different capabilities of GPIO and Timed I/O
> > > as a single PCI function through shared MMIO.
> 
> ...
> 
> > > +	ret = pci_alloc_irq_vectors(pci, 2, 2, PCI_IRQ_ALL_TYPES);
> > > +	if (ret < 0)
> > > +		return ret;
> > > +
> > > +	ret = mfd_add_devices(&pci->dev, PLATFORM_DEVID_AUTO, ehl_pse_gpio_devs,
> > 
> > dev_*?
> 
> devm_* ?

Yes, typo.

> > > +			      ARRAY_SIZE(ehl_pse_gpio_devs), pci_resource_n(pci, 0),
> > > +			      pci_irq_vector(pci, 0), NULL);
> > > +	if (ret)
> > > +		pci_free_irq_vectors(pci);
> 
> Anyway, the choice as far as I understood it is motivated by usage of
> pci_*_irq_vector() APIs, which are officially not manageable (however
> in practice they are).
> 
> > > +	return ret;
> > > +}
> > > +
> > > +static void ehl_pse_gpio_remove(struct pci_dev *pdev)
> > > +{
> > > +	mfd_remove_devices(&pdev->dev);
> > > +	pci_free_irq_vectors(pdev);
> > > +}
> 
> Same here.

Also, Greg has been quite vocal about converting PCI devices to Platform
ones in the past.  We may wish to run this past him before continuing.

-- 
Lee Jones [李琼斯]

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Andy Shevchenko]

On Fri, Mar 14, 2025 at 01:57:35PM +0000, Lee Jones wrote:
> On Fri, 14 Mar 2025, Andy Shevchenko wrote:
> > On Fri, Mar 14, 2025 at 12:44:50PM +0000, Lee Jones wrote:
> > > On Fri, 07 Mar 2025, Raag Jadav wrote:

...

> > > > +	ret = pci_alloc_irq_vectors(pci, 2, 2, PCI_IRQ_ALL_TYPES);
> > > > +	if (ret < 0)
> > > > +		return ret;
> > > > +
> > > > +	ret = mfd_add_devices(&pci->dev, PLATFORM_DEVID_AUTO, ehl_pse_gpio_devs,
> > > 
> > > dev_*?
> > 
> > devm_* ?
> 
> Yes, typo.
> 
> > > > +			      ARRAY_SIZE(ehl_pse_gpio_devs), pci_resource_n(pci, 0),
> > > > +			      pci_irq_vector(pci, 0), NULL);
> > > > +	if (ret)
> > > > +		pci_free_irq_vectors(pci);
> > 
> > Anyway, the choice as far as I understood it is motivated by usage of
> > pci_*_irq_vector() APIs, which are officially not manageable (however
> > in practice they are).
> > 
> > > > +	return ret;
> > > > +}
> > > > +
> > > > +static void ehl_pse_gpio_remove(struct pci_dev *pdev)
> > > > +{
> > > > +	mfd_remove_devices(&pdev->dev);
> > > > +	pci_free_irq_vectors(pdev);
> > > > +}
> > 
> > Same here.
> 
> Also, Greg has been quite vocal about converting PCI devices to Platform
> ones in the past.  We may wish to run this past him before continuing.

What do you refer to? Any links to read?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Raag Jadav]

On Fri, Mar 14, 2025 at 04:20:35PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 14, 2025 at 01:57:35PM +0000, Lee Jones wrote:
> > On Fri, 14 Mar 2025, Andy Shevchenko wrote:
> > > On Fri, Mar 14, 2025 at 12:44:50PM +0000, Lee Jones wrote:
> > > > On Fri, 07 Mar 2025, Raag Jadav wrote:
> 
> ...
> 
> > > > > +	ret = pci_alloc_irq_vectors(pci, 2, 2, PCI_IRQ_ALL_TYPES);
> > > > > +	if (ret < 0)
> > > > > +		return ret;
> > > > > +
> > > > > +	ret = mfd_add_devices(&pci->dev, PLATFORM_DEVID_AUTO, ehl_pse_gpio_devs,
> > > > 
> > > > dev_*?
> > > 
> > > devm_* ?
> > 
> > Yes, typo.
> > 
> > > > > +			      ARRAY_SIZE(ehl_pse_gpio_devs), pci_resource_n(pci, 0),
> > > > > +			      pci_irq_vector(pci, 0), NULL);
> > > > > +	if (ret)
> > > > > +		pci_free_irq_vectors(pci);
> > > 
> > > Anyway, the choice as far as I understood it is motivated by usage of
> > > pci_*_irq_vector() APIs, which are officially not manageable (however
> > > in practice they are).

Are you referring to pcim_setup_msi_release()? I saw it but wasn't confident
it is in the call path, so went with manual release instead.

Now that you mentioned it, will update.

> > > > > +	return ret;
> > > > > +}
> > > > > +
> > > > > +static void ehl_pse_gpio_remove(struct pci_dev *pdev)
> > > > > +{
> > > > > +	mfd_remove_devices(&pdev->dev);
> > > > > +	pci_free_irq_vectors(pdev);
> > > > > +}
> > > 
> > > Same here.
> > 
> > Also, Greg has been quite vocal about converting PCI devices to Platform
> > ones in the past.  We may wish to run this past him before continuing.
> 
> What do you refer to? Any links to read?

Could be about faux_device, but I could be wrong since here we do use
platform resources.

Raag

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Raag Jadav]

On Fri, Mar 14, 2025 at 01:57:35PM +0000, Lee Jones wrote:
> On Fri, 14 Mar 2025, Andy Shevchenko wrote:
> > On Fri, Mar 14, 2025 at 12:44:50PM +0000, Lee Jones wrote:
> > > On Fri, 07 Mar 2025, Raag Jadav wrote:

...

> > > > +static void ehl_pse_gpio_remove(struct pci_dev *pdev)
> > > > +{
> > > > +	mfd_remove_devices(&pdev->dev);
> > > > +	pci_free_irq_vectors(pdev);
> > > > +}
> > 
> > Same here.
> 
> Also, Greg has been quite vocal about converting PCI devices to Platform
> ones in the past.  We may wish to run this past him before continuing.

Greg, any objections on moving forward with platform device?

Raag

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Greg KH]

On Fri, Mar 21, 2025 at 07:28:22AM +0200, Raag Jadav wrote:
> On Fri, Mar 14, 2025 at 01:57:35PM +0000, Lee Jones wrote:
> > On Fri, 14 Mar 2025, Andy Shevchenko wrote:
> > > On Fri, Mar 14, 2025 at 12:44:50PM +0000, Lee Jones wrote:
> > > > On Fri, 07 Mar 2025, Raag Jadav wrote:
> 
> ...
> 
> > > > > +static void ehl_pse_gpio_remove(struct pci_dev *pdev)
> > > > > +{
> > > > > +	mfd_remove_devices(&pdev->dev);
> > > > > +	pci_free_irq_vectors(pdev);
> > > > > +}
> > > 
> > > Same here.
> > 
> > Also, Greg has been quite vocal about converting PCI devices to Platform
> > ones in the past.  We may wish to run this past him before continuing.
> 
> Greg, any objections on moving forward with platform device?

I have no context here at all, why would a PCI device EVER be a platform
device?  That feels wrong on so many levels...

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Andy Shevchenko]

On Fri, Mar 21, 2025 at 06:04:38AM -0700, Greg KH wrote:
> On Fri, Mar 21, 2025 at 07:28:22AM +0200, Raag Jadav wrote:
> > On Fri, Mar 14, 2025 at 01:57:35PM +0000, Lee Jones wrote:
> > > On Fri, 14 Mar 2025, Andy Shevchenko wrote:

...

> > > Also, Greg has been quite vocal about converting PCI devices to Platform
> > > ones in the past.  We may wish to run this past him before continuing.
> > 
> > Greg, any objections on moving forward with platform device?
> 
> I have no context here at all, why would a PCI device EVER be a platform
> device?  That feels wrong on so many levels...

It's a multi-functional device, in other words that device provides a set of
(dependent or independent) subdevices. But do you have other suggestion?
The auxiliary bus?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Greg KH]

On Fri, Mar 21, 2025 at 03:22:36PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 21, 2025 at 06:04:38AM -0700, Greg KH wrote:
> > On Fri, Mar 21, 2025 at 07:28:22AM +0200, Raag Jadav wrote:
> > > On Fri, Mar 14, 2025 at 01:57:35PM +0000, Lee Jones wrote:
> > > > On Fri, 14 Mar 2025, Andy Shevchenko wrote:
> 
> ...
> 
> > > > Also, Greg has been quite vocal about converting PCI devices to Platform
> > > > ones in the past.  We may wish to run this past him before continuing.
> > > 
> > > Greg, any objections on moving forward with platform device?
> > 
> > I have no context here at all, why would a PCI device EVER be a platform
> > device?  That feels wrong on so many levels...
> 
> It's a multi-functional device, in other words that device provides a set of
> (dependent or independent) subdevices. But do you have other suggestion?
> The auxiliary bus?

Yes, that is exactly what the auxiliary bus code was designed and
written for.

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Andy Shevchenko]

On Tue, Mar 25, 2025 at 08:45:29PM -0400, Greg KH wrote:
> On Fri, Mar 21, 2025 at 03:22:36PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 21, 2025 at 06:04:38AM -0700, Greg KH wrote:
> > > On Fri, Mar 21, 2025 at 07:28:22AM +0200, Raag Jadav wrote:
> > > > On Fri, Mar 14, 2025 at 01:57:35PM +0000, Lee Jones wrote:
> > > > > On Fri, 14 Mar 2025, Andy Shevchenko wrote:

...

> > > > > Also, Greg has been quite vocal about converting PCI devices to Platform
> > > > > ones in the past.  We may wish to run this past him before continuing.
> > > > 
> > > > Greg, any objections on moving forward with platform device?
> > > 
> > > I have no context here at all, why would a PCI device EVER be a platform
> > > device?  That feels wrong on so many levels...
> > 
> > It's a multi-functional device, in other words that device provides a set of
> > (dependent or independent) subdevices. But do you have other suggestion?
> > The auxiliary bus?
> 
> Yes, that is exactly what the auxiliary bus code was designed and
> written for.

Lee, what do you think of extending mfd to cover this case, i.e. specifically
for the PCI devices? Or maybe it makes sense to go to the auxiliary bus
completely (I think this may break a lot of things on legacy systems, though).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/5] mfd: intel_ehl_pse_gpio: Introduce Intel Elkhart Lake PSE GPIO and TIO

[Greg KH]

On Wed, Mar 26, 2025 at 11:01:52AM +0200, Andy Shevchenko wrote:
> On Tue, Mar 25, 2025 at 08:45:29PM -0400, Greg KH wrote:
> > On Fri, Mar 21, 2025 at 03:22:36PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 21, 2025 at 06:04:38AM -0700, Greg KH wrote:
> > > > On Fri, Mar 21, 2025 at 07:28:22AM +0200, Raag Jadav wrote:
> > > > > On Fri, Mar 14, 2025 at 01:57:35PM +0000, Lee Jones wrote:
> > > > > > On Fri, 14 Mar 2025, Andy Shevchenko wrote:
> 
> ...
> 
> > > > > > Also, Greg has been quite vocal about converting PCI devices to Platform
> > > > > > ones in the past.  We may wish to run this past him before continuing.
> > > > > 
> > > > > Greg, any objections on moving forward with platform device?
> > > > 
> > > > I have no context here at all, why would a PCI device EVER be a platform
> > > > device?  That feels wrong on so many levels...
> > > 
> > > It's a multi-functional device, in other words that device provides a set of
> > > (dependent or independent) subdevices. But do you have other suggestion?
> > > The auxiliary bus?
> > 
> > Yes, that is exactly what the auxiliary bus code was designed and
> > written for.
> 
> Lee, what do you think of extending mfd to cover this case, i.e. specifically
> for the PCI devices? Or maybe it makes sense to go to the auxiliary bus
> completely (I think this may break a lot of things on legacy systems, though).

Don't change existing drivers, only do it for new ones please.

[PATCH v3 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

Now that we have Intel MFD driver for PSE GPIO, depend on it.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
---
 drivers/gpio/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 98b4d1633b25..232ef211ef38 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1372,7 +1372,7 @@ config HTC_EGPIO
 
 config GPIO_ELKHARTLAKE
 	tristate "Intel Elkhart Lake PSE GPIO support"
-	depends on X86 || COMPILE_TEST
+	depends on (X86 || COMPILE_TEST) && MFD_INTEL_EHL_PSE_GPIO
 	select GPIO_TANGIER
 	help
 	  Select this option to enable GPIO support for Intel Elkhart Lake
-- 
2.34.1

Re: [PATCH v3 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

On Fri, Mar 07, 2025 at 10:52:28AM +0530, Raag Jadav wrote:
> Now that we have Intel MFD driver for PSE GPIO, depend on it.
> 
> Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> ---

Andy, any guidance on GPIO?

Raag

>  drivers/gpio/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 98b4d1633b25..232ef211ef38 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1372,7 +1372,7 @@ config HTC_EGPIO
>  
>  config GPIO_ELKHARTLAKE
>  	tristate "Intel Elkhart Lake PSE GPIO support"
> -	depends on X86 || COMPILE_TEST
> +	depends on (X86 || COMPILE_TEST) && MFD_INTEL_EHL_PSE_GPIO
>  	select GPIO_TANGIER
>  	help
>  	  Select this option to enable GPIO support for Intel Elkhart Lake
> -- 
> 2.34.1
> 

Re: [PATCH v3 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Andy Shevchenko]

On Tue, Mar 11, 2025 at 08:37:26AM +0200, Raag Jadav wrote:
> On Fri, Mar 07, 2025 at 10:52:28AM +0530, Raag Jadav wrote:
> > Now that we have Intel MFD driver for PSE GPIO, depend on it.

> Andy, any guidance on GPIO?

I'm not sure what we are waiting here from me. Hadn't I reviewed your GPIO
part already?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

On Wed, Mar 12, 2025 at 01:00:35PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 11, 2025 at 08:37:26AM +0200, Raag Jadav wrote:
> > On Fri, Mar 07, 2025 at 10:52:28AM +0530, Raag Jadav wrote:
> > > Now that we have Intel MFD driver for PSE GPIO, depend on it.
> 
> > Andy, any guidance on GPIO?
> 
> I'm not sure what we are waiting here from me. Hadn't I reviewed your GPIO
> part already?

Ah, I added MFD dependency for leaf drivers after your v1 review.
So this one seems missing the tag. Can I add it?

Raag

Re: [PATCH v3 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Andy Shevchenko]

On Wed, Mar 12, 2025 at 07:03:01PM +0200, Raag Jadav wrote:
> On Wed, Mar 12, 2025 at 01:00:35PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 11, 2025 at 08:37:26AM +0200, Raag Jadav wrote:
> > > On Fri, Mar 07, 2025 at 10:52:28AM +0530, Raag Jadav wrote:
> > > > Now that we have Intel MFD driver for PSE GPIO, depend on it.
> > 
> > > Andy, any guidance on GPIO?
> > 
> > I'm not sure what we are waiting here from me. Hadn't I reviewed your GPIO
> > part already?
> 
> Ah, I added MFD dependency for leaf drivers after your v1 review.
> So this one seems missing the tag. Can I add it?

I see, but this can be added later on.
And on the second thought, do we accept the configurations
when user wants to have GPIO on EHL, and doesn't care about TIO?
Maybe this patch is not needed after all?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

On Wed, Mar 12, 2025 at 08:32:51PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 12, 2025 at 07:03:01PM +0200, Raag Jadav wrote:
> > On Wed, Mar 12, 2025 at 01:00:35PM +0200, Andy Shevchenko wrote:
> > > On Tue, Mar 11, 2025 at 08:37:26AM +0200, Raag Jadav wrote:
> > > > On Fri, Mar 07, 2025 at 10:52:28AM +0530, Raag Jadav wrote:
> > > > > Now that we have Intel MFD driver for PSE GPIO, depend on it.
> > > 
> > > > Andy, any guidance on GPIO?
> > > 
> > > I'm not sure what we are waiting here from me. Hadn't I reviewed your GPIO
> > > part already?
> > 
> > Ah, I added MFD dependency for leaf drivers after your v1 review.
> > So this one seems missing the tag. Can I add it?
> 
> I see, but this can be added later on.
> And on the second thought, do we accept the configurations
> when user wants to have GPIO on EHL, and doesn't care about TIO?

Yes, here we're making the leaf driver (GPIO) depend on MFD regardless
of what TIO config is.

> Maybe this patch is not needed after all?

My understanding is that GPIO should depend on MFD. Not much point in
adding a standalone leaf driver right?

Raag

Re: [PATCH v3 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Andy Shevchenko]

On Thu, Mar 13, 2025 at 11:19:28AM +0200, Raag Jadav wrote:
> On Wed, Mar 12, 2025 at 08:32:51PM +0200, Andy Shevchenko wrote:
> > On Wed, Mar 12, 2025 at 07:03:01PM +0200, Raag Jadav wrote:
> > > On Wed, Mar 12, 2025 at 01:00:35PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Mar 11, 2025 at 08:37:26AM +0200, Raag Jadav wrote:
> > > > > On Fri, Mar 07, 2025 at 10:52:28AM +0530, Raag Jadav wrote:
> > > > > > Now that we have Intel MFD driver for PSE GPIO, depend on it.
> > > > 
> > > > > Andy, any guidance on GPIO?
> > > > 
> > > > I'm not sure what we are waiting here from me. Hadn't I reviewed your GPIO
> > > > part already?
> > > 
> > > Ah, I added MFD dependency for leaf drivers after your v1 review.
> > > So this one seems missing the tag. Can I add it?
> > 
> > I see, but this can be added later on.
> > And on the second thought, do we accept the configurations
> > when user wants to have GPIO on EHL, and doesn't care about TIO?
> 
> Yes, here we're making the leaf driver (GPIO) depend on MFD regardless
> of what TIO config is.
> 
> > Maybe this patch is not needed after all?
> 
> My understanding is that GPIO should depend on MFD. Not much point in
> adding a standalone leaf driver right?

Ah, indeed, we have no other means to enumerate it (as we don't have any board
file that does direct creation of the device), this patch is correct.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

[Raag Jadav]

On Thu, Mar 13, 2025 at 04:00:01PM +0200, Andy Shevchenko wrote:
> On Thu, Mar 13, 2025 at 11:19:28AM +0200, Raag Jadav wrote:
> > On Wed, Mar 12, 2025 at 08:32:51PM +0200, Andy Shevchenko wrote:
> > > On Wed, Mar 12, 2025 at 07:03:01PM +0200, Raag Jadav wrote:
> > > > On Wed, Mar 12, 2025 at 01:00:35PM +0200, Andy Shevchenko wrote:
> > > > > On Tue, Mar 11, 2025 at 08:37:26AM +0200, Raag Jadav wrote:
> > > > > > On Fri, Mar 07, 2025 at 10:52:28AM +0530, Raag Jadav wrote:
> > > > > > > Now that we have Intel MFD driver for PSE GPIO, depend on it.
> > > > > 
> > > > > > Andy, any guidance on GPIO?
> > > > > 
> > > > > I'm not sure what we are waiting here from me. Hadn't I reviewed your GPIO
> > > > > part already?
> > > > 
> > > > Ah, I added MFD dependency for leaf drivers after your v1 review.
> > > > So this one seems missing the tag. Can I add it?
> > > 
> > > I see, but this can be added later on.
> > > And on the second thought, do we accept the configurations
> > > when user wants to have GPIO on EHL, and doesn't care about TIO?
> > 
> > Yes, here we're making the leaf driver (GPIO) depend on MFD regardless
> > of what TIO config is.
> > 
> > > Maybe this patch is not needed after all?
> > 
> > My understanding is that GPIO should depend on MFD. Not much point in
> > adding a standalone leaf driver right?
> 
> Ah, indeed, we have no other means to enumerate it (as we don't have any board
> file that does direct creation of the device), this patch is correct.
> 
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Awesome.

I'm guessing this series will only apply on Greg's tree due to TIO stuff.
If I'd rather need to route it any other way, please let me know.

Raag

[PATCH v3 3/5] pps: generators: tio: split pps_gen_tio.h

[Raag Jadav]

Split macros and structure definition to header file for better
maintainability.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/pps/generators/pps_gen_tio.c | 30 +----------------
 drivers/pps/generators/pps_gen_tio.h | 49 ++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+), 29 deletions(-)
 create mode 100644 drivers/pps/generators/pps_gen_tio.h

diff --git a/drivers/pps/generators/pps_gen_tio.c b/drivers/pps/generators/pps_gen_tio.c
index 6c46b46c66cd..7f2aab1219af 100644
--- a/drivers/pps/generators/pps_gen_tio.c
+++ b/drivers/pps/generators/pps_gen_tio.c
@@ -5,8 +5,6 @@
  * Copyright (C) 2024 Intel Corporation
  */
 
-#include <linux/bitfield.h>
-#include <linux/bits.h>
 #include <linux/cleanup.h>
 #include <linux/container_of.h>
 #include <linux/device.h>
@@ -21,33 +19,7 @@
 
 #include <asm/cpu_device_id.h>
 
-#define TIOCTL			0x00
-#define TIOCOMPV		0x10
-#define TIOEC			0x30
-
-/* Control Register */
-#define TIOCTL_EN			BIT(0)
-#define TIOCTL_DIR			BIT(1)
-#define TIOCTL_EP			GENMASK(3, 2)
-#define TIOCTL_EP_RISING_EDGE		FIELD_PREP(TIOCTL_EP, 0)
-#define TIOCTL_EP_FALLING_EDGE		FIELD_PREP(TIOCTL_EP, 1)
-#define TIOCTL_EP_TOGGLE_EDGE		FIELD_PREP(TIOCTL_EP, 2)
-
-/* Safety time to set hrtimer early */
-#define SAFE_TIME_NS			(10 * NSEC_PER_MSEC)
-
-#define MAGIC_CONST			(NSEC_PER_SEC - SAFE_TIME_NS)
-#define ART_HW_DELAY_CYCLES		2
-
-struct pps_tio {
-	struct pps_gen_source_info gen_info;
-	struct pps_gen_device *pps_gen;
-	struct hrtimer timer;
-	void __iomem *base;
-	u32 prev_count;
-	spinlock_t lock;
-	struct device *dev;
-};
+#include "pps_gen_tio.h"
 
 static inline u32 pps_tio_read(u32 offset, struct pps_tio *tio)
 {
diff --git a/drivers/pps/generators/pps_gen_tio.h b/drivers/pps/generators/pps_gen_tio.h
new file mode 100644
index 000000000000..5033d5efdf92
--- /dev/null
+++ b/drivers/pps/generators/pps_gen_tio.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Intel PPS signal Generator Driver
+ *
+ * Copyright (C) 2025 Intel Corporation
+ */
+
+#ifndef _PPS_GEN_TIO_H_
+#define _PPS_GEN_TIO_H_
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/hrtimer.h>
+#include <linux/pps_gen_kernel.h>
+#include <linux/spinlock_types.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+struct device;
+
+#define TIOCTL			0x00
+#define TIOCOMPV		0x10
+#define TIOEC			0x30
+
+/* Control Register */
+#define TIOCTL_EN			BIT(0)
+#define TIOCTL_DIR			BIT(1)
+#define TIOCTL_EP			GENMASK(3, 2)
+#define TIOCTL_EP_RISING_EDGE		FIELD_PREP(TIOCTL_EP, 0)
+#define TIOCTL_EP_FALLING_EDGE		FIELD_PREP(TIOCTL_EP, 1)
+#define TIOCTL_EP_TOGGLE_EDGE		FIELD_PREP(TIOCTL_EP, 2)
+
+/* Safety time to set hrtimer early */
+#define SAFE_TIME_NS			(10 * NSEC_PER_MSEC)
+
+#define MAGIC_CONST			(NSEC_PER_SEC - SAFE_TIME_NS)
+#define ART_HW_DELAY_CYCLES		2
+
+struct pps_tio {
+	struct pps_gen_source_info gen_info;
+	struct pps_gen_device *pps_gen;
+	struct hrtimer timer;
+	void __iomem *base;
+	u32 prev_count;
+	spinlock_t lock;
+	struct device *dev;
+};
+
+#endif /* _PPS_GEN_TIO_H_ */
-- 
2.34.1

[PATCH v3 4/5] pps: generators: tio: move to match_data() model

[Raag Jadav]

Use device_get_match_data() which allows configuring platform
specific data like number of pins and MMIO registers for TIO.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/pps/generators/pps_gen_tio.c | 33 ++++++++++++++++++++--------
 drivers/pps/generators/pps_gen_tio.h | 19 +++++++++++++---
 2 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/pps/generators/pps_gen_tio.c b/drivers/pps/generators/pps_gen_tio.c
index 7f2aab1219af..6e3a4b198259 100644
--- a/drivers/pps/generators/pps_gen_tio.c
+++ b/drivers/pps/generators/pps_gen_tio.c
@@ -14,6 +14,7 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/pps_gen_kernel.h>
+#include <linux/property.h>
 #include <linux/timekeeping.h>
 #include <linux/types.h>
 
@@ -28,7 +29,7 @@ static inline u32 pps_tio_read(u32 offset, struct pps_tio *tio)
 
 static inline void pps_ctl_write(u32 value, struct pps_tio *tio)
 {
-	writel(value, tio->base + TIOCTL);
+	writel(value, tio->base + tio->regs.ctl);
 }
 
 /*
@@ -37,7 +38,7 @@ static inline void pps_ctl_write(u32 value, struct pps_tio *tio)
  */
 static inline void pps_compv_write(u64 value, struct pps_tio *tio)
 {
-	hi_lo_writeq(value, tio->base + TIOCOMPV);
+	hi_lo_writeq(value, tio->base + tio->regs.compv);
 }
 
 static inline ktime_t first_event(struct pps_tio *tio)
@@ -49,7 +50,7 @@ static u32 pps_tio_disable(struct pps_tio *tio)
 {
 	u32 ctrl;
 
-	ctrl = pps_tio_read(TIOCTL, tio);
+	ctrl = pps_tio_read(tio->regs.ctl, tio);
 	pps_compv_write(0, tio);
 
 	ctrl &= ~TIOCTL_EN;
@@ -63,7 +64,7 @@ static void pps_tio_enable(struct pps_tio *tio)
 {
 	u32 ctrl;
 
-	ctrl = pps_tio_read(TIOCTL, tio);
+	ctrl = pps_tio_read(tio->regs.ctl, tio);
 	ctrl |= TIOCTL_EN;
 	pps_ctl_write(ctrl, tio);
 	tio->pps_gen->enabled = true;
@@ -112,7 +113,7 @@ static enum hrtimer_restart hrtimer_callback(struct hrtimer *timer)
 	 * Check if any event is missed.
 	 * If an event is missed, TIO will be disabled.
 	 */
-	event_count = pps_tio_read(TIOEC, tio);
+	event_count = pps_tio_read(tio->regs.ec, tio);
 	if (tio->prev_count && tio->prev_count == event_count)
 		goto err;
 	tio->prev_count = event_count;
@@ -172,6 +173,7 @@ static int pps_tio_get_time(struct pps_gen_device *pps_gen,
 static int pps_gen_tio_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
+	const struct pps_tio_data *data;
 	struct pps_tio *tio;
 
 	if (!(cpu_feature_enabled(X86_FEATURE_TSC_KNOWN_FREQ) &&
@@ -184,6 +186,11 @@ static int pps_gen_tio_probe(struct platform_device *pdev)
 	if (!tio)
 		return -ENOMEM;
 
+	data = device_get_match_data(dev);
+	if (!data)
+		return -ENODEV;
+
+	tio->regs = data->regs;
 	tio->gen_info.use_system_clock = true;
 	tio->gen_info.enable = pps_tio_gen_enable;
 	tio->gen_info.get_time = pps_tio_get_time;
@@ -216,11 +223,19 @@ static void pps_gen_tio_remove(struct platform_device *pdev)
 	pps_gen_unregister_source(tio->pps_gen);
 }
 
+static const struct pps_tio_data pmc_data = {
+	.regs = {
+		.ctl = TIOCTL_PMC,
+		.compv = TIOCOMPV_PMC,
+		.ec = TIOEC_PMC,
+	},
+};
+
 static const struct acpi_device_id intel_pmc_tio_acpi_match[] = {
-	{ "INTC1021" },
-	{ "INTC1022" },
-	{ "INTC1023" },
-	{ "INTC1024" },
+	{ "INTC1021", (kernel_ulong_t)&pmc_data },
+	{ "INTC1022", (kernel_ulong_t)&pmc_data },
+	{ "INTC1023", (kernel_ulong_t)&pmc_data },
+	{ "INTC1024", (kernel_ulong_t)&pmc_data },
 	{}
 };
 MODULE_DEVICE_TABLE(acpi, intel_pmc_tio_acpi_match);
diff --git a/drivers/pps/generators/pps_gen_tio.h b/drivers/pps/generators/pps_gen_tio.h
index 5033d5efdf92..4329b6dbd598 100644
--- a/drivers/pps/generators/pps_gen_tio.h
+++ b/drivers/pps/generators/pps_gen_tio.h
@@ -18,9 +18,10 @@
 
 struct device;
 
-#define TIOCTL			0x00
-#define TIOCOMPV		0x10
-#define TIOEC			0x30
+/* PMC Registers */
+#define TIOCTL_PMC			0x00
+#define TIOCOMPV_PMC			0x10
+#define TIOEC_PMC			0x30
 
 /* Control Register */
 #define TIOCTL_EN			BIT(0)
@@ -36,9 +37,21 @@ struct device;
 #define MAGIC_CONST			(NSEC_PER_SEC - SAFE_TIME_NS)
 #define ART_HW_DELAY_CYCLES		2
 
+struct pps_tio_regs {
+	u32 ctl;
+	u32 compv;
+	u32 ec;
+};
+
+struct pps_tio_data {
+	struct pps_tio_regs regs;
+	u32 num_pins;
+};
+
 struct pps_tio {
 	struct pps_gen_source_info gen_info;
 	struct pps_gen_device *pps_gen;
+	struct pps_tio_regs regs;
 	struct hrtimer timer;
 	void __iomem *base;
 	u32 prev_count;
-- 
2.34.1

[PATCH v3 5/5] pps: generators: tio: Introduce Intel Elkhart Lake PSE TIO

[Raag Jadav]

Add initial support for Intel Elkhart Lake PSE TIO controller.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/pps/generators/Kconfig       |  2 +-
 drivers/pps/generators/pps_gen_tio.c | 17 ++++++++++++++++-
 drivers/pps/generators/pps_gen_tio.h |  5 +++++
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/pps/generators/Kconfig b/drivers/pps/generators/Kconfig
index b3f340ed3163..83aada693ad2 100644
--- a/drivers/pps/generators/Kconfig
+++ b/drivers/pps/generators/Kconfig
@@ -33,7 +33,7 @@ config PPS_GENERATOR_PARPORT
 
 config PPS_GENERATOR_TIO
 	tristate "TIO PPS signal generator"
-	depends on X86 && CPU_SUP_INTEL
+	depends on X86 && CPU_SUP_INTEL && MFD_INTEL_EHL_PSE_GPIO
 	help
 	  If you say yes here you get support for a PPS TIO signal generator
 	  which generates a pulse at a prescribed time based on the system clock.
diff --git a/drivers/pps/generators/pps_gen_tio.c b/drivers/pps/generators/pps_gen_tio.c
index 6e3a4b198259..a2a23cdc2568 100644
--- a/drivers/pps/generators/pps_gen_tio.c
+++ b/drivers/pps/generators/pps_gen_tio.c
@@ -231,6 +231,14 @@ static const struct pps_tio_data pmc_data = {
 	},
 };
 
+static const struct pps_tio_data ehl_pse_data = {
+	.regs = {
+		.ctl = TIOCTL_PSE,
+		.compv = TIOCOMPV_PSE,
+		.ec = TIOEC_PSE,
+	},
+};
+
 static const struct acpi_device_id intel_pmc_tio_acpi_match[] = {
 	{ "INTC1021", (kernel_ulong_t)&pmc_data },
 	{ "INTC1022", (kernel_ulong_t)&pmc_data },
@@ -240,9 +248,16 @@ static const struct acpi_device_id intel_pmc_tio_acpi_match[] = {
 };
 MODULE_DEVICE_TABLE(acpi, intel_pmc_tio_acpi_match);
 
+static const struct platform_device_id pps_gen_tio_ids[] = {
+	{ "pps-gen-tio", (kernel_ulong_t)&ehl_pse_data },
+	{ }
+};
+MODULE_DEVICE_TABLE(platform, pps_gen_tio_ids);
+
 static struct platform_driver pps_gen_tio_driver = {
 	.probe          = pps_gen_tio_probe,
 	.remove         = pps_gen_tio_remove,
+	.id_table	= pps_gen_tio_ids,
 	.driver         = {
 		.name                   = "intel-pps-gen-tio",
 		.acpi_match_table       = intel_pmc_tio_acpi_match,
@@ -255,5 +270,5 @@ MODULE_AUTHOR("Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>");
 MODULE_AUTHOR("Pandith N <pandith.n@intel.com>");
 MODULE_AUTHOR("Thejesh Reddy T R <thejesh.reddy.t.r@intel.com>");
 MODULE_AUTHOR("Subramanian Mohan <subramanian.mohan@intel.com>");
-MODULE_DESCRIPTION("Intel PMC Time-Aware IO Generator Driver");
+MODULE_DESCRIPTION("Intel Time-Aware IO Generator Driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/pps/generators/pps_gen_tio.h b/drivers/pps/generators/pps_gen_tio.h
index 4329b6dbd598..509bd2633dfb 100644
--- a/drivers/pps/generators/pps_gen_tio.h
+++ b/drivers/pps/generators/pps_gen_tio.h
@@ -18,6 +18,11 @@
 
 struct device;
 
+/* EHL PSE Registers */
+#define TIOCTL_PSE			0x00
+#define TIOCOMPV_PSE			0x04
+#define TIOEC_PSE			0x24
+
 /* PMC Registers */
 #define TIOCTL_PMC			0x00
 #define TIOCOMPV_PMC			0x10
-- 
2.34.1