| Message ID | 20200822040508.23510-2-rajmohan.mani@intel.com (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
| Series | Add Intel Input Output Manager driver | expand |
Hi Rajmohan, On Fri, Aug 21, 2020 at 09:05:06PM -0700, Rajmohan Mani wrote: > Input Output Manager (IOM) is part of the Tiger Lake SoC that > configures the Type-C Sub System (TCSS). IOM is a micro controller > that handles Type-C topology, configuration and PM functions of > various Type-C devices connected on the platform. > > This driver helps read relevant information such as Type-C port > status (whether a device is connected to a Type-C port or not) and > the activity type on the Type-C ports (such as USB, Display Port, > Thunderbolt), for consumption by other drivers. > > Currently intel_iom_port_status() API is exported by this driver, > that has information about the Type-C port status and port activity > type. > > Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> > --- Perhaps include a version log of changes since v1? > diff --git a/drivers/platform/x86/intel_iom.c b/drivers/platform/x86/intel_iom.c > new file mode 100644 > index 000000000000..cda7716410c6 > --- /dev/null > +++ b/drivers/platform/x86/intel_iom.c > +int intel_iom_port_status(u8 port, u32 *status) > +{ > + void __iomem *reg; > + > + if (!iom || !iom->dev || !iom->regbar) Do we need to check for !iom->dev and !iom->regbar? Is there a valid situation where iom != NULL but iom->dev and/or iom->regbar == NULL? Sounds like it shouldn't, but I may be missing something. > + return -ENODEV; > + > + if (!status || (port > IOM_MAX_PORTS - 1)) I think parentheses around "port > IOM_MAX_PORT - 1" aren't required. > + return -EINVAL; > + > + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN * port; > + > + *status = ioread32(reg); Perhaps just inline reg within the parentheses? > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(intel_iom_port_status); > + > +static int intel_iom_probe(struct platform_device *pdev) > +{ > + void __iomem *addr; > + > + /* only one IOM device is supported */ Minor nit: s/only/Only > + if (iom) > + return -EBUSY; > + > + iom = devm_kzalloc(&pdev->dev, sizeof(*iom), GFP_KERNEL); > + if (!iom) > + return -ENOMEM; > + > + addr = devm_platform_ioremap_resource(pdev, 0); > + if (IS_ERR(addr)) > + return PTR_ERR(addr); > + > + iom->regbar = addr; > + iom->dev = &pdev->dev; > + > + return 0; > +} > + > +static const struct acpi_device_id intel_iom_acpi_ids[] = { > + { "INTC1072" }, > + {} > +}; > +MODULE_DEVICE_TABLE(acpi, intel_iom_acpi_ids); > + > +static struct platform_driver intel_iom_driver = { > + .probe = intel_iom_probe, nit: I generally see ".probe" listed below ".driver". > + .driver = { > + .name = "intel_iom", > + .acpi_match_table = intel_iom_acpi_ids, > + }, > +}; > + > +module_platform_driver_probe(intel_iom_driver, intel_iom_probe); > + > +MODULE_AUTHOR("Rajmohan Mani <rajmohan.mani@intel.com>"); > +MODULE_DESCRIPTION("Intel IOM driver"); > +MODULE_LICENSE("GPL v2"); > diff --git a/include/linux/platform_data/x86/intel_iom.h b/include/linux/platform_data/x86/intel_iom.h > new file mode 100644 > index 000000000000..e4c9a305e7a9 > --- /dev/null > +++ b/include/linux/platform_data/x86/intel_iom.h > @@ -0,0 +1,49 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +#ifndef _PLATFORM_DATA_X86_INTEL_IOM_H_ > +#define _PLATFORM_DATA_X86_INTEL_IOM_H_ > + > + > +#define IOM_MAX_PORTS 4 > +/* Register length in bytes */ > +#define IOM_REG_LEN 4 Do these two #define's need to be in the header, instead of directly in intel_iom.c ? > + > +#ifdef CONFIG_ACPI > + > +int intel_iom_port_status(u8 port, u32 *status); > + > +#else > + > +int intel_iom_port_status(struct intel_iom *iom, u8 port, u32 *status) Should the function signature be the same as the #ifdef case? Best regards, -Prashant
Hi Prashant, Thanks for the quick review. > Subject: Re: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager > (IOM) driver > > Hi Rajmohan, > > On Fri, Aug 21, 2020 at 09:05:06PM -0700, Rajmohan Mani wrote: > > Input Output Manager (IOM) is part of the Tiger Lake SoC that > > configures the Type-C Sub System (TCSS). IOM is a micro controller > > that handles Type-C topology, configuration and PM functions of > > various Type-C devices connected on the platform. > > > > This driver helps read relevant information such as Type-C port status > > (whether a device is connected to a Type-C port or not) and the > > activity type on the Type-C ports (such as USB, Display Port, > > Thunderbolt), for consumption by other drivers. > > > > Currently intel_iom_port_status() API is exported by this driver, that > > has information about the Type-C port status and port activity type. > > > > Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> > > --- > > Perhaps include a version log of changes since v1? Yes. It's there in the cover letter (patch v2 0/3). > > diff --git a/drivers/platform/x86/intel_iom.c > > b/drivers/platform/x86/intel_iom.c > > new file mode 100644 > > index 000000000000..cda7716410c6 > > --- /dev/null > > +++ b/drivers/platform/x86/intel_iom.c > > +int intel_iom_port_status(u8 port, u32 *status) { > > + void __iomem *reg; > > + > > + if (!iom || !iom->dev || !iom->regbar) > > Do we need to check for !iom->dev and !iom->regbar? It's a good practice to have sanity checks on pointer members dereferenced. So I can lose the check on iom->dev, but prefer to keep the check on regbar. Let me know if you feel strongly about losing the check for regbar as well. > Is there a valid situation > where iom != NULL but iom->dev and/or iom->regbar == NULL? > Sounds like it shouldn't, but I may be missing something. > I think I am being conservative here. > > + return -ENODEV; > > + > > + if (!status || (port > IOM_MAX_PORTS - 1)) > > I think parentheses around "port > IOM_MAX_PORT - 1" aren't required. Ack > > + return -EINVAL; > > + > > + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN * > port; > > + > > + *status = ioread32(reg); > > Perhaps just inline reg within the parentheses? Kept this way to increase readability. Let me know if you feel strongly towards inline reg. > > + > > + return 0; > > +} > > +EXPORT_SYMBOL_GPL(intel_iom_port_status); > > + > > +static int intel_iom_probe(struct platform_device *pdev) { > > + void __iomem *addr; > > + > > + /* only one IOM device is supported */ > > Minor nit: s/only/Only And then I may need to end the comment with a period. Let me know if you feel strongly. > > + if (iom) > > + return -EBUSY; > > + > > + iom = devm_kzalloc(&pdev->dev, sizeof(*iom), GFP_KERNEL); > > + if (!iom) > > + return -ENOMEM; > > + > > + addr = devm_platform_ioremap_resource(pdev, 0); > > + if (IS_ERR(addr)) > > + return PTR_ERR(addr); > > + > > + iom->regbar = addr; > > + iom->dev = &pdev->dev; > > + > > + return 0; > > +} > > + > > +static const struct acpi_device_id intel_iom_acpi_ids[] = { > > + { "INTC1072" }, > > + {} > > +}; > > +MODULE_DEVICE_TABLE(acpi, intel_iom_acpi_ids); > > + > > +static struct platform_driver intel_iom_driver = { > > + .probe = intel_iom_probe, > > nit: I generally see ".probe" listed below ".driver". Ack > > + .driver = { > > + .name = "intel_iom", > > + .acpi_match_table = intel_iom_acpi_ids, > > + }, > > +}; > > + > > +module_platform_driver_probe(intel_iom_driver, intel_iom_probe); > > + > > +MODULE_AUTHOR("Rajmohan Mani <rajmohan.mani@intel.com>"); > > +MODULE_DESCRIPTION("Intel IOM driver"); MODULE_LICENSE("GPL v2"); > > diff --git a/include/linux/platform_data/x86/intel_iom.h > > b/include/linux/platform_data/x86/intel_iom.h > > new file mode 100644 > > index 000000000000..e4c9a305e7a9 > > --- /dev/null > > +++ b/include/linux/platform_data/x86/intel_iom.h > > @@ -0,0 +1,49 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > + > > +#ifndef _PLATFORM_DATA_X86_INTEL_IOM_H_ #define > > +_PLATFORM_DATA_X86_INTEL_IOM_H_ > > + > > + > > +#define IOM_MAX_PORTS 4 > > +/* Register length in bytes */ > > +#define IOM_REG_LEN 4 > > Do these two #define's need to be in the header, instead of directly in > intel_iom.c ? > Ack. These 2 can be moved to .c file. > > + > > +#ifdef CONFIG_ACPI > > + > > +int intel_iom_port_status(u8 port, u32 *status); > > + > > +#else > > + > > +int intel_iom_port_status(struct intel_iom *iom, u8 port, u32 > > +*status) > > Should the function signature be the same as the #ifdef case? > Thanks for catching this. I missed it.
Hi Rajmohan, On Mon, Aug 24, 2020 at 10:19:27PM +0000, Mani, Rajmohan wrote: > Hi Prashant, > > Thanks for the quick review. > > > > + > > > + if (!iom || !iom->dev || !iom->regbar) > > > > Do we need to check for !iom->dev and !iom->regbar? > > It's a good practice to have sanity checks on pointer members dereferenced. > > So I can lose the check on iom->dev, but prefer to keep the check on regbar. > Let me know if you feel strongly about losing the check for regbar as well. Sounds good. > > > Is there a valid situation > > where iom != NULL but iom->dev and/or iom->regbar == NULL? > > Sounds like it shouldn't, but I may be missing something. > > > > I think I am being conservative here. > > > > + return -ENODEV; > > > + > > > + if (!status || (port > IOM_MAX_PORTS - 1)) > > > > I think parentheses around "port > IOM_MAX_PORT - 1" aren't required. > > Ack > > > > + return -EINVAL; > > > + > > > + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN * > > port; > > > + > > > + *status = ioread32(reg); > > > > Perhaps just inline reg within the parentheses? > > Kept this way to increase readability. Let me know if you feel strongly towards > inline reg. I'd rather this be inlined, you save a couple lines from the variable declaration, and IMO we're not gaining much in terms of readability by declaring this separately. > > > > + > > > + return 0; > > > +} > > > +EXPORT_SYMBOL_GPL(intel_iom_port_status); > > > + > > > +static int intel_iom_probe(struct platform_device *pdev) { > > > + void __iomem *addr; > > > + > > > + /* only one IOM device is supported */ > > > > Minor nit: s/only/Only > > And then I may need to end the comment with a period. > Let me know if you feel strongly. Yes, let's capitalize and add the period. Let's try to use the right punctuation where possible. Best regards, -Prashant
Hi Prashant, ... > > > > + > > > > + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN * > > > port; > > > > + > > > > + *status = ioread32(reg); > > > > > > Perhaps just inline reg within the parentheses? > > > > Kept this way to increase readability. Let me know if you feel > > strongly towards inline reg. > > I'd rather this be inlined, you save a couple lines from the variable declaration, > and IMO we're not gaining much in terms of readability by declaring this > separately. > Ack (at least to me, it was more readable) ... > > > > > > + > > > > + return 0; > > > > +} > > > > +EXPORT_SYMBOL_GPL(intel_iom_port_status); > > > > + > > > > +static int intel_iom_probe(struct platform_device *pdev) { > > > > + void __iomem *addr; > > > > + > > > > + /* only one IOM device is supported */ > > > > > > Minor nit: s/only/Only > > > > And then I may need to end the comment with a period. > > Let me know if you feel strongly. > Yes, let's capitalize and add the period. Let's try to use the right punctuation > where possible. > Ack Will take care of this as part of v3.
On Fri, Aug 21, 2020 at 09:05:06PM -0700, Rajmohan Mani wrote: > Input Output Manager (IOM) is part of the Tiger Lake SoC that > configures the Type-C Sub System (TCSS). IOM is a micro controller > that handles Type-C topology, configuration and PM functions of > various Type-C devices connected on the platform. > > This driver helps read relevant information such as Type-C port > status (whether a device is connected to a Type-C port or not) and > the activity type on the Type-C ports (such as USB, Display Port, > Thunderbolt), for consumption by other drivers. > > Currently intel_iom_port_status() API is exported by this driver, > that has information about the Type-C port status and port activity > type. > > Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> > --- > drivers/platform/x86/Kconfig | 16 ++++ > drivers/platform/x86/Makefile | 1 + > drivers/platform/x86/intel_iom.c | 95 +++++++++++++++++++++ > include/linux/platform_data/x86/intel_iom.h | 49 +++++++++++ > 4 files changed, 161 insertions(+) > create mode 100644 drivers/platform/x86/intel_iom.c > create mode 100644 include/linux/platform_data/x86/intel_iom.h > > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig > index 40219bba6801..f09b4b525ea5 100644 > --- a/drivers/platform/x86/Kconfig > +++ b/drivers/platform/x86/Kconfig > @@ -837,6 +837,22 @@ config INTEL_INT0002_VGPIO > To compile this driver as a module, choose M here: the module will > be called intel_int0002_vgpio. > > +config INTEL_IOM > + tristate "Intel Input Output Manager (IOM) driver" > + depends on ACPI && PCI > + help > + This driver helps read relevant information such as Type-C port > + status (whether a device is connected to a Type-C port or not) > + and the activity type on the Type-C ports (such as USB, Display > + Port, Thunderbolt), for consumption by other drivers. > + > + Currently intel_iom_port_status() API is exported by this driver, > + that has information about the Type-C port status and port activity > + type. > + > + To compile this driver as a module, choose M here: the module will > + be called intel_iom. > + > config INTEL_MENLOW > tristate "Thermal Management driver for Intel menlow platform" > depends on ACPI_THERMAL > diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile > index 5f823f7eff45..b44f706074c3 100644 > --- a/drivers/platform/x86/Makefile > +++ b/drivers/platform/x86/Makefile > @@ -77,6 +77,7 @@ intel_cht_int33fe-objs := intel_cht_int33fe_common.o \ > intel_cht_int33fe_microb.o > obj-$(CONFIG_INTEL_HID_EVENT) += intel-hid.o > obj-$(CONFIG_INTEL_INT0002_VGPIO) += intel_int0002_vgpio.o > +obj-$(CONFIG_INTEL_IOM) += intel_iom.o > obj-$(CONFIG_INTEL_MENLOW) += intel_menlow.o > obj-$(CONFIG_INTEL_OAKTRAIL) += intel_oaktrail.o > obj-$(CONFIG_INTEL_VBTN) += intel-vbtn.o > diff --git a/drivers/platform/x86/intel_iom.c b/drivers/platform/x86/intel_iom.c > new file mode 100644 > index 000000000000..cda7716410c6 > --- /dev/null > +++ b/drivers/platform/x86/intel_iom.c > @@ -0,0 +1,95 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Intel Core SoC Input Output Manager (IOM) driver. > + * > + * This driver provides access to the Input Output Manager (IOM) (that > + * is part of Tiger Lake SoC) registers that can be used to know about > + * Type-C Sub System related information (such as Type-C port status, > + * activity type on Type-C ports). > + * > + * Copyright (C) 2020, Intel Corporation > + * Author: Rajmohan Mani <rajmohan.mani@intel.com> > + */ > + > +#include <linux/io.h> > +#include <linux/mod_devicetable.h> > +#include <linux/module.h> > +#include <linux/platform_data/x86/intel_iom.h> > +#include <linux/platform_device.h> > +#include <linux/slab.h> > + > +#define IOM_PORT_STATUS_OFFSET 0x560 > + > +struct intel_iom { > + struct device *dev; > + void __iomem *regbar; > +}; > + > +static struct intel_iom *iom; > + > +/** > + * intel_iom_port_status() - Get status bits for the Type-C port > + * @port: Type-C port number > + * @status: pointer to receive the status bits > + * > + * Returns 0 on success, error otherwise. > + */ > +int intel_iom_port_status(u8 port, u32 *status) > +{ > + void __iomem *reg; > + > + if (!iom || !iom->dev || !iom->regbar) > + return -ENODEV; > + > + if (!status || (port > IOM_MAX_PORTS - 1)) > + return -EINVAL; > + > + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN * port; > + > + *status = ioread32(reg); > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(intel_iom_port_status); > + > +static int intel_iom_probe(struct platform_device *pdev) > +{ > + void __iomem *addr; > + > + /* only one IOM device is supported */ > + if (iom) > + return -EBUSY; > + > + iom = devm_kzalloc(&pdev->dev, sizeof(*iom), GFP_KERNEL); > + if (!iom) > + return -ENOMEM; > + > + addr = devm_platform_ioremap_resource(pdev, 0); > + if (IS_ERR(addr)) > + return PTR_ERR(addr); > + > + iom->regbar = addr; > + iom->dev = &pdev->dev; > + > + return 0; > +} > + > +static const struct acpi_device_id intel_iom_acpi_ids[] = { > + { "INTC1072" }, > + {} > +}; > +MODULE_DEVICE_TABLE(acpi, intel_iom_acpi_ids); > + > +static struct platform_driver intel_iom_driver = { > + .probe = intel_iom_probe, > + .driver = { > + .name = "intel_iom", > + .acpi_match_table = intel_iom_acpi_ids, > + }, > +}; > + > +module_platform_driver_probe(intel_iom_driver, intel_iom_probe); > + > +MODULE_AUTHOR("Rajmohan Mani <rajmohan.mani@intel.com>"); > +MODULE_DESCRIPTION("Intel IOM driver"); > +MODULE_LICENSE("GPL v2"); I still find this crazy that a whole separate driver is created just to read a single 32bit value. Why not put this logic in the driver that wants to read that value? That would be much simpler, smaller, and more obvious. thanks, greg k-h
Hi Greg, On Fri, Aug 28, 2020 at 09:43:59AM +0200, Greg Kroah-Hartman wrote: > I still find this crazy that a whole separate driver is created just to > read a single 32bit value. > > Why not put this logic in the driver that wants to read that value? > That would be much simpler, smaller, and more obvious. That would mean that we start maintaining something like DMI quirk table in those drivers. Unfortunately the IOM device is not available on every platform. Also, even on platforms that do have it, there is no guarantee that the device is always going to be mapped to the same address. Nevertheless, I was originally hoping that we could hide the handling of IOM somehow in ACPI without the need for an actual device object, but it now turns out that the other features of the IOM chip have created interest. At least our i915 guys probable have some use for it (I don't know exactly what they are planning to use it for). So the fact that we may later need the device for something else, on top of the clumsiness and most importantly risks involved with using ACPI to take care of extra tasks (ASL tends to have bugs - bugs that may never ever get fixed), I think the IOM device object, and the driver that binds to it, do have a valid reason for existing. thanks,
On Fri, Aug 28, 2020 at 12:08:32PM +0300, Heikki Krogerus wrote: > Hi Greg, > > On Fri, Aug 28, 2020 at 09:43:59AM +0200, Greg Kroah-Hartman wrote: > > I still find this crazy that a whole separate driver is created just to > > read a single 32bit value. > > > > Why not put this logic in the driver that wants to read that value? > > That would be much simpler, smaller, and more obvious. > > That would mean that we start maintaining something like DMI quirk > table in those drivers. Unfortunately the IOM device is not available > on every platform. Also, even on platforms that do have it, there is > no guarantee that the device is always going to be mapped to the same > address. Ok, but putting it in another driver has the same problem as you are now depending on that driver with the driver that calls this, right? The quirk table would go in here, but not somewhere else? And if this really is only for typec stuff, put it in the typec directory, not burried off in the platform driver subdir please. > Nevertheless, I was originally hoping that we could hide the handling > of IOM somehow in ACPI without the need for an actual device object, > but it now turns out that the other features of the IOM chip have > created interest. At least our i915 guys probable have some use for it > (I don't know exactly what they are planning to use it for). > > So the fact that we may later need the device for something else, on > top of the clumsiness and most importantly risks involved with using > ACPI to take care of extra tasks (ASL tends to have bugs - bugs that > may never ever get fixed), I think the IOM device object, and the > driver that binds to it, do have a valid reason for existing. Handle the situation today, if, in the future, someone else needs/wants this, _then_ work on splitting it out into separate pieces. Don't create additional complexity today, for no benefit today. It's already caused numerous review comments/complaints the way this is designed... thanks, greg k-h
On Fri, Aug 28, 2020 at 12:03:35PM +0200, Greg Kroah-Hartman wrote: > Handle the situation today, if, in the future, someone else needs/wants > this, _then_ work on splitting it out into separate pieces. Don't > create additional complexity today, for no benefit today. It's already > caused numerous review comments/complaints the way this is designed... OK. We'll handle this in the mux driver for now. thanks,
Hi Greg, > Subject: Re: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager > (IOM) driver > > Hi Greg, > > On Fri, Aug 28, 2020 at 09:43:59AM +0200, Greg Kroah-Hartman wrote: > > I still find this crazy that a whole separate driver is created just > > to read a single 32bit value. > > > > Why not put this logic in the driver that wants to read that value? > > That would be much simpler, smaller, and more obvious. > > That would mean that we start maintaining something like DMI quirk table in > those drivers. Unfortunately the IOM device is not available on every platform. > Also, even on platforms that do have it, there is no guarantee that the device is > always going to be mapped to the same address. > > Nevertheless, I was originally hoping that we could hide the handling of IOM > somehow in ACPI without the need for an actual device object, but it now > turns out that the other features of the IOM chip have created interest. At > least our i915 guys probable have some use for it (I don't know exactly what > they are planning to use it for). > > So the fact that we may later need the device for something else, on top of the > clumsiness and most importantly risks involved with using ACPI to take care of > extra tasks (ASL tends to have bugs - bugs that may never ever get fixed), I > think the IOM device object, and the driver that binds to it, do have a valid > reason for existing. > Intel PMC USB mux device is part of the PCH, while IOM is part of the SoC. This was another reason we had to have a separate ACPI device. > > thanks, > > -- > heikki
> Subject: Re: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager > (IOM) driver > > On Fri, Aug 28, 2020 at 12:03:35PM +0200, Greg Kroah-Hartman wrote: > > Handle the situation today, if, in the future, someone else > > needs/wants this, _then_ work on splitting it out into separate > > pieces. Don't create additional complexity today, for no benefit > > today. It's already caused numerous review comments/complaints the way > this is designed... > > OK. We'll handle this in the mux driver for now. > Ack. Will work with Heikki on this. > > thanks, > > -- > heikki
On Fri, Aug 28, 2020 at 03:20:22PM +0000, Mani, Rajmohan wrote: > Hi Greg, > > > Subject: Re: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager > > (IOM) driver > > > > Hi Greg, > > > > On Fri, Aug 28, 2020 at 09:43:59AM +0200, Greg Kroah-Hartman wrote: > > > I still find this crazy that a whole separate driver is created just > > > to read a single 32bit value. > > > > > > Why not put this logic in the driver that wants to read that value? > > > That would be much simpler, smaller, and more obvious. > > > > That would mean that we start maintaining something like DMI quirk table in > > those drivers. Unfortunately the IOM device is not available on every platform. > > Also, even on platforms that do have it, there is no guarantee that the device is > > always going to be mapped to the same address. > > > > Nevertheless, I was originally hoping that we could hide the handling of IOM > > somehow in ACPI without the need for an actual device object, but it now > > turns out that the other features of the IOM chip have created interest. At > > least our i915 guys probable have some use for it (I don't know exactly what > > they are planning to use it for). > > > > So the fact that we may later need the device for something else, on top of the > > clumsiness and most importantly risks involved with using ACPI to take care of > > extra tasks (ASL tends to have bugs - bugs that may never ever get fixed), I > > think the IOM device object, and the driver that binds to it, do have a valid > > reason for existing. > > > > Intel PMC USB mux device is part of the PCH, while IOM is part of the SoC. I have no idea what a "PCH" is, what "IOM" is, and how any of this relates to a "SoC" :) Don't impose arbritrary hardware "splits" to kernel code when the kernel has no such "partitioning" please. > This was another reason we had to have a separate ACPI device. That sounds like a firmware issue you can solve in UEFI. I think this is the most TLA-laden email I have ever written, and I used to work at IBM :) greg k-h
Hi Greg, > Subject: Re: [PATCH v2 1/3] platform/x86: Add Intel Input Output Manager > (IOM) driver > > On Fri, Aug 28, 2020 at 03:20:22PM +0000, Mani, Rajmohan wrote: > > Hi Greg, > > > > > Subject: Re: [PATCH v2 1/3] platform/x86: Add Intel Input Output > > > Manager > > > (IOM) driver > > > > > > Hi Greg, > > > > > > On Fri, Aug 28, 2020 at 09:43:59AM +0200, Greg Kroah-Hartman wrote: > > > > I still find this crazy that a whole separate driver is created > > > > just to read a single 32bit value. > > > > > > > > Why not put this logic in the driver that wants to read that value? > > > > That would be much simpler, smaller, and more obvious. > > > > > > That would mean that we start maintaining something like DMI quirk > > > table in those drivers. Unfortunately the IOM device is not available on > every platform. > > > Also, even on platforms that do have it, there is no guarantee that > > > the device is always going to be mapped to the same address. > > > > > > Nevertheless, I was originally hoping that we could hide the > > > handling of IOM somehow in ACPI without the need for an actual > > > device object, but it now turns out that the other features of the > > > IOM chip have created interest. At least our i915 guys probable have > > > some use for it (I don't know exactly what they are planning to use it for). > > > > > > So the fact that we may later need the device for something else, on > > > top of the clumsiness and most importantly risks involved with using > > > ACPI to take care of extra tasks (ASL tends to have bugs - bugs that > > > may never ever get fixed), I think the IOM device object, and the > > > driver that binds to it, do have a valid reason for existing. > > > > > > > Intel PMC USB mux device is part of the PCH, while IOM is part of the SoC. > > I have no idea what a "PCH" is, what "IOM" is, and how any of this relates to a > "SoC" :) > I was just meaning to say IOM (Intel Output Manager) is a separate device, that is not part of PCH (Platform Controller Hub) like PMC (Power Management Controller). For the sake of completeness PCH - Platform Controller Hub (usually that handles I/Os in Intel core platforms) IOM - Input Output Manager (IOM) is part of the Tiger Lake SoC that handles Type-C topology, configuration and PM functions of various Type-C devices connected on the platform > Don't impose arbritrary hardware "splits" to kernel code when the kernel has > no such "partitioning" please. > Ack. > > This was another reason we had to have a separate ACPI device. > > That sounds like a firmware issue you can solve in UEFI. > Ack > I think this is the most TLA-laden email I have ever written, and I used to work > at IBM :) I thought it was only Intel where TLAs are abundantly used. Thanks for the reviews and the direction on this topic. > > greg k-h
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index 40219bba6801..f09b4b525ea5 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -837,6 +837,22 @@ config INTEL_INT0002_VGPIO To compile this driver as a module, choose M here: the module will be called intel_int0002_vgpio. +config INTEL_IOM + tristate "Intel Input Output Manager (IOM) driver" + depends on ACPI && PCI + help + This driver helps read relevant information such as Type-C port + status (whether a device is connected to a Type-C port or not) + and the activity type on the Type-C ports (such as USB, Display + Port, Thunderbolt), for consumption by other drivers. + + Currently intel_iom_port_status() API is exported by this driver, + that has information about the Type-C port status and port activity + type. + + To compile this driver as a module, choose M here: the module will + be called intel_iom. + config INTEL_MENLOW tristate "Thermal Management driver for Intel menlow platform" depends on ACPI_THERMAL diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile index 5f823f7eff45..b44f706074c3 100644 --- a/drivers/platform/x86/Makefile +++ b/drivers/platform/x86/Makefile @@ -77,6 +77,7 @@ intel_cht_int33fe-objs := intel_cht_int33fe_common.o \ intel_cht_int33fe_microb.o obj-$(CONFIG_INTEL_HID_EVENT) += intel-hid.o obj-$(CONFIG_INTEL_INT0002_VGPIO) += intel_int0002_vgpio.o +obj-$(CONFIG_INTEL_IOM) += intel_iom.o obj-$(CONFIG_INTEL_MENLOW) += intel_menlow.o obj-$(CONFIG_INTEL_OAKTRAIL) += intel_oaktrail.o obj-$(CONFIG_INTEL_VBTN) += intel-vbtn.o diff --git a/drivers/platform/x86/intel_iom.c b/drivers/platform/x86/intel_iom.c new file mode 100644 index 000000000000..cda7716410c6 --- /dev/null +++ b/drivers/platform/x86/intel_iom.c @@ -0,0 +1,95 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Intel Core SoC Input Output Manager (IOM) driver. + * + * This driver provides access to the Input Output Manager (IOM) (that + * is part of Tiger Lake SoC) registers that can be used to know about + * Type-C Sub System related information (such as Type-C port status, + * activity type on Type-C ports). + * + * Copyright (C) 2020, Intel Corporation + * Author: Rajmohan Mani <rajmohan.mani@intel.com> + */ + +#include <linux/io.h> +#include <linux/mod_devicetable.h> +#include <linux/module.h> +#include <linux/platform_data/x86/intel_iom.h> +#include <linux/platform_device.h> +#include <linux/slab.h> + +#define IOM_PORT_STATUS_OFFSET 0x560 + +struct intel_iom { + struct device *dev; + void __iomem *regbar; +}; + +static struct intel_iom *iom; + +/** + * intel_iom_port_status() - Get status bits for the Type-C port + * @port: Type-C port number + * @status: pointer to receive the status bits + * + * Returns 0 on success, error otherwise. + */ +int intel_iom_port_status(u8 port, u32 *status) +{ + void __iomem *reg; + + if (!iom || !iom->dev || !iom->regbar) + return -ENODEV; + + if (!status || (port > IOM_MAX_PORTS - 1)) + return -EINVAL; + + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN * port; + + *status = ioread32(reg); + + return 0; +} +EXPORT_SYMBOL_GPL(intel_iom_port_status); + +static int intel_iom_probe(struct platform_device *pdev) +{ + void __iomem *addr; + + /* only one IOM device is supported */ + if (iom) + return -EBUSY; + + iom = devm_kzalloc(&pdev->dev, sizeof(*iom), GFP_KERNEL); + if (!iom) + return -ENOMEM; + + addr = devm_platform_ioremap_resource(pdev, 0); + if (IS_ERR(addr)) + return PTR_ERR(addr); + + iom->regbar = addr; + iom->dev = &pdev->dev; + + return 0; +} + +static const struct acpi_device_id intel_iom_acpi_ids[] = { + { "INTC1072" }, + {} +}; +MODULE_DEVICE_TABLE(acpi, intel_iom_acpi_ids); + +static struct platform_driver intel_iom_driver = { + .probe = intel_iom_probe, + .driver = { + .name = "intel_iom", + .acpi_match_table = intel_iom_acpi_ids, + }, +}; + +module_platform_driver_probe(intel_iom_driver, intel_iom_probe); + +MODULE_AUTHOR("Rajmohan Mani <rajmohan.mani@intel.com>"); +MODULE_DESCRIPTION("Intel IOM driver"); +MODULE_LICENSE("GPL v2"); diff --git a/include/linux/platform_data/x86/intel_iom.h b/include/linux/platform_data/x86/intel_iom.h new file mode 100644 index 000000000000..e4c9a305e7a9 --- /dev/null +++ b/include/linux/platform_data/x86/intel_iom.h @@ -0,0 +1,49 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _PLATFORM_DATA_X86_INTEL_IOM_H_ +#define _PLATFORM_DATA_X86_INTEL_IOM_H_ + +#include <linux/bits.h> +#include <linux/types.h> + +/* Input Output Manager (IOM) PORT STATUS */ +#define IOM_PORT_STATUS_ACTIVITY_TYPE_MASK GENMASK(9, 6) +#define IOM_PORT_STATUS_ACTIVITY_TYPE_SHIFT 0x06 +#define IOM_PORT_STATUS_ACTIVITY_TYPE_USB 0x03 +/* activity type: Safe Mode */ +#define IOM_PORT_STATUS_ACTIVITY_TYPE_SAFE_MODE 0x04 +/* activity type: Display Port */ +#define IOM_PORT_STATUS_ACTIVITY_TYPE_DP 0x05 +/* activity type: Display Port Multi Function Device */ +#define IOM_PORT_STATUS_ACTIVITY_TYPE_DP_MFD 0x06 +/* activity type: Thunderbolt */ +#define IOM_PORT_STATUS_ACTIVITY_TYPE_TBT 0x07 +#define IOM_PORT_STATUS_ACTIVITY_TYPE_ALT_MODE_USB 0x0c +#define IOM_PORT_STATUS_ACTIVITY_TYPE_ALT_MODE_TBT_USB 0x0d +/* Upstream Facing Port Information */ +#define IOM_PORT_STATUS_UFP BIT(10) +/* Display Port Hot Plug Detect status */ +#define IOM_PORT_STATUS_DHPD_HPD_STATUS_MASK GENMASK(13, 12) +#define IOM_PORT_STATUS_DHPD_HPD_STATUS_SHIFT 0x0c +#define IOM_PORT_STATUS_DHPD_HPD_STATUS_ASSERT 0x01 +#define IOM_PORT_STATUS_DHPD_HPD_SOURCE_TBT BIT(14) +#define IOM_PORT_STATUS_CONNECTED BIT(31) + +#define IOM_MAX_PORTS 4 +/* Register length in bytes */ +#define IOM_REG_LEN 4 + +#ifdef CONFIG_ACPI + +int intel_iom_port_status(u8 port, u32 *status); + +#else + +int intel_iom_port_status(struct intel_iom *iom, u8 port, u32 *status) +{ + return 0; +} + +#endif + +#endif /* _PLATFORM_DATA_X86_INTEL_IOM_H_ */
Input Output Manager (IOM) is part of the Tiger Lake SoC that configures the Type-C Sub System (TCSS). IOM is a micro controller that handles Type-C topology, configuration and PM functions of various Type-C devices connected on the platform. This driver helps read relevant information such as Type-C port status (whether a device is connected to a Type-C port or not) and the activity type on the Type-C ports (such as USB, Display Port, Thunderbolt), for consumption by other drivers. Currently intel_iom_port_status() API is exported by this driver, that has information about the Type-C port status and port activity type. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> --- drivers/platform/x86/Kconfig | 16 ++++ drivers/platform/x86/Makefile | 1 + drivers/platform/x86/intel_iom.c | 95 +++++++++++++++++++++ include/linux/platform_data/x86/intel_iom.h | 49 +++++++++++ 4 files changed, 161 insertions(+) create mode 100644 drivers/platform/x86/intel_iom.c create mode 100644 include/linux/platform_data/x86/intel_iom.h