linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Scally <djrscally@gmail.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org,
	linux-media@vger.kernel.org, devel@acpica.org, rjw@rjwysocki.net,
	lenb@kernel.org, gregkh@linuxfoundation.org,
	mika.westerberg@linux.intel.com,
	andriy.shevchenko@linux.intel.com, linus.walleij@linaro.org,
	bgolaszewski@baylibre.com, wsa@kernel.org, yong.zhi@intel.com,
	sakari.ailus@linux.intel.com, bingbu.cao@intel.com,
	tian.shu.qiu@intel.com, mchehab@kernel.org,
	robert.moore@intel.com, erik.kaneda@intel.com, pmladek@suse.com,
	rostedt@goodmis.org, sergey.senozhatsky@gmail.com,
	linux@rasmusvillemoes.dk,
	kieran.bingham+renesas@ideasonboard.com,
	jacopo+renesas@jmondi.org,
	laurent.pinchart+renesas@ideasonboard.com,
	jorhand@linux.microsoft.com, kitakar@gmail.com,
	heikki.krogerus@linux.intel.com,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 18/18] ipu3: Add driver for dummy INT3472 ACPI device
Date: Mon, 30 Nov 2020 23:06:03 +0000	[thread overview]
Message-ID: <3e8494a0-a2c0-59e7-46bb-9635c3c239dd@gmail.com> (raw)
In-Reply-To: <20201130205203.GQ4351@valkosipuli.retiisi.org.uk>

Hi Sakari

On 30/11/2020 20:52, Sakari Ailus wrote:
>> +static const struct acpi_device_id int3472_device_id[] = {
>> +	{ "INT3472", 0 },
> The INT3472 _HID is really allocated for the tps68470 PMIC chip. It may not
> be used by other drivers; people will want to build kernels where both of
> these ACPI table layouts are functional.
>
> Instead, I propose, that you add this as an option to the tps68470 driver
> that figures out whether the ACPI device for the tps68470 device actually
> describes something else, in a similar fashion you do with the cio2-bridge
> driver. I think it may need a separate Kconfig option albeit this and
> cio2-bridge cannot be used separately.

It actually occurs to me that that may not work (I know I called that
out as an option we considered, but that was a while ago actually). The
reason I wasn't worried about the existing tps68470 driver binding to
these devices is that it's an i2c driver, and these dummy devices don't
have an I2cSerialBusV2, so no I2C device is created by them the kernel.


Won't that mean the tps68470 driver won't ever be probed for these devices?

>
>> +	{ },
>> +};
>> +MODULE_DEVICE_TABLE(acpi, int3472_device_id);
>> +
>> +static struct acpi_driver int3472_driver = {
>> +	.name = "int3472",
>> +	.ids = int3472_device_id,
>> +	.ops = {
>> +		.add = int3472_add,
>> +		.remove = int3472_remove,
>> +	},
>> +	.owner = THIS_MODULE,
>> +};
>> +
>> +module_acpi_driver(int3472_driver);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_AUTHOR("Dan Scally <djrscally@gmail.com>");
>> +MODULE_DESCRIPTION("ACPI Driver for Discrete type INT3472 ACPI Devices");
>> diff --git a/drivers/media/pci/intel/ipu3/int3472.h b/drivers/media/pci/intel/ipu3/int3472.h
>> new file mode 100644
>> index 000000000000..6964726e8e1f
>> --- /dev/null
>> +++ b/drivers/media/pci/intel/ipu3/int3472.h
>> @@ -0,0 +1,96 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Author: Dan Scally <djrscally@gmail.com> */
>> +#include <linux/regulator/machine.h>
>> +
>> +#define INT3472_MAX_SENSOR_GPIOS			3
>> +#define GPIO_REGULATOR_NAME_LENGTH			17
>> +#define GPIO_REGULATOR_SUPPLY_NAME_LENGTH		9
>> +
>> +#define INT3472_REGULATOR(_NAME, _SUPPLY, _ID, _OPS)	\
>> +	((const struct regulator_desc) {		\
>> +		.name = _NAME,				\
>> +		.supply_name = _SUPPLY,			\
>> +		.id = _ID,				\
>> +		.type = REGULATOR_VOLTAGE,		\
>> +		.ops = _OPS,				\
>> +		.owner = THIS_MODULE,			\
>> +	})
>> +
>> +const guid_t int3472_gpio_guid = GUID_INIT(0x79234640, 0x9e10, 0x4fea,
>> +					     0xa5, 0xc1, 0xb5, 0xaa, 0x8b,
>> +					     0x19, 0x75, 0x6f);
>> +
>> +const guid_t cio2_sensor_module_guid = GUID_INIT(0x822ace8f, 0x2814, 0x4174,
>> +						 0xa5, 0x6b, 0x5f, 0x02, 0x9f,
>> +						 0xe0, 0x79, 0xee);
>> +
>> +struct int3472_cldb {
>> +	u8 version;
>> +	/*
>> +	 * control logic type
>> +	 * 0: UNKNOWN
>> +	 * 1: DISCRETE(CRD-D)
>> +	 * 2: PMIC TPS68470
>> +	 * 3: PMIC uP6641
>> +	 */
>> +	u8 control_logic_type;
>> +	u8 control_logic_id;
>> +	u8 sensor_card_sku;
>> +	u8 reserved[28];
>> +};
>> +
>> +struct int3472_device {
>> +	struct acpi_device *adev;
>> +	struct acpi_device *sensor;
>> +
>> +	unsigned int n_gpios; /* how many GPIOs have we seen */
>> +
>> +	unsigned int n_regulators;
>> +	struct list_head regulators;
>> +
>> +	unsigned int n_sensor_gpios; /* how many have we mapped to sensor */
>> +	struct gpiod_lookup_table gpios;
>> +};
>> +
>> +struct int3472_gpio_regulator {
>> +	char regulator_name[GPIO_REGULATOR_NAME_LENGTH];
>> +	char supply_name[GPIO_REGULATOR_SUPPLY_NAME_LENGTH];
>> +	struct gpio_desc *gpio;
>> +	struct regulator_dev *rdev;
>> +	struct regulator_desc rdesc;
>> +	struct list_head list;
>> +};
>> +
>> +struct int3472_sensor_regulator_map {
>> +	char *sensor_module_name;
>> +	unsigned int n_supplies;
>> +	struct regulator_consumer_supply *supplies;
>> +};
>> +
>> +/*
>> + * Here follows platform specific mapping information that we can pass to
>> + * regulator_init_data when we register our regulators. They're just mapped
>> + * via index, I.E. the first regulator pin that the code finds for the
>> + * i2c-OVTI2680:00 device is avdd, the second is dovdd and so on.
>> + */
>> +
>> +static struct regulator_consumer_supply miix_510_ov2680[] = {
>> +	{ "i2c-OVTI2680:00", "avdd" },
>> +	{ "i2c-OVTI2680:00", "dovdd" },
>> +};
>> +
>> +static struct regulator_consumer_supply surface_go2_ov5693[] = {
>> +	{ "i2c-INT33BE:00", "avdd" },
>> +	{ "i2c-INT33BE:00", "dovdd" },
>> +};
>> +
>> +static struct regulator_consumer_supply surface_book_ov5693[] = {
>> +	{ "i2c-INT33BE:00", "avdd" },
>> +	{ "i2c-INT33BE:00", "dovdd" },
>> +};
>> +
>> +static struct int3472_sensor_regulator_map int3472_sensor_regulator_maps[] = {
>> +	{ "GNDF140809R", 2, miix_510_ov2680 },
>> +	{ "YHCU", 2, surface_go2_ov5693 },
>> +	{ "MSHW0070", 2, surface_book_ov5693 },
>> +};

  reply	other threads:[~2020-11-30 23:06 UTC|newest]

Thread overview: 144+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30 13:31 [PATCH 00/18] Add functionality to ipu3-cio2 driver allowing software_node connections to sensors on platforms designed for Windows Daniel Scally
2020-11-30 13:31 ` [PATCH 01/18] property: Return true in fwnode_device_is_available for node types that do not implement this operation Daniel Scally
2020-11-30 16:05   ` Laurent Pinchart
2020-11-30 17:21   ` Andy Shevchenko
2020-12-01  3:12   ` Bingbu Cao
2020-12-01  8:46     ` Dan Scally
2020-11-30 13:31 ` [PATCH 02/18] property: Add support for calling fwnode_graph_get_endpoint_by_id() for fwnode->secondary Daniel Scally
2020-11-30 16:08   ` Laurent Pinchart
2020-11-30 17:29   ` Andy Shevchenko
2020-11-30 17:28     ` Laurent Pinchart
2020-11-30 17:53       ` Andy Shevchenko
2020-11-30 18:41         ` Laurent Pinchart
2020-11-30 19:21           ` Andy Shevchenko
2020-12-02 10:13     ` Dan Scally
2020-11-30 13:31 ` [PATCH 03/18] software_node: Fix failure to put() and get() references to children in software_node_get_next_child() Daniel Scally
2020-11-30 16:10   ` Laurent Pinchart
2020-11-30 17:30   ` Andy Shevchenko
2020-11-30 13:31 ` [PATCH 04/18] software_node: Enforce parent before child ordering of nodes array for software_node_register_nodes() Daniel Scally
2020-11-30 16:11   ` Laurent Pinchart
2020-11-30 16:12     ` Laurent Pinchart
2020-11-30 23:10       ` Dan Scally
2020-11-30 17:35   ` Andy Shevchenko
2020-11-30 17:37     ` Andy Shevchenko
2020-11-30 13:31 ` [PATCH 05/18] software_node: Alter software_node_unregister_nodes() to unregister the array in reverse order Daniel Scally
2020-11-30 16:14   ` Laurent Pinchart
2020-11-30 17:45   ` Andy Shevchenko
2020-12-01 23:36     ` Dan Scally
2020-11-30 13:31 ` [PATCH 06/18] software_node: amend software_node_unregister_node_group() to perform unregistration of array in reverse order to be consistent with software_node_unregister_nodes() Daniel Scally
2020-11-30 16:17   ` Laurent Pinchart
2020-11-30 17:47     ` Andy Shevchenko
2020-12-02 10:04       ` Dan Scally
2020-11-30 17:19   ` kernel test robot
2020-12-01 18:18   ` Dan Carpenter
2020-11-30 13:31 ` [PATCH 07/18] software_node: Add support for fwnode_graph*() family of functions Daniel Scally
2020-11-30 16:25   ` Laurent Pinchart
2020-11-30 23:34     ` Dan Scally
2020-11-30 13:31 ` [PATCH 08/18] lib/test_printf.c: Use helper function to unwind array of software_nodes Daniel Scally
2020-11-30 15:54   ` Sergey Senozhatsky
2020-11-30 16:26   ` Laurent Pinchart
2020-11-30 13:31 ` [PATCH 09/18] ipu3-cio2: Add T: entry to MAINTAINERS Daniel Scally
2020-11-30 13:31 ` [PATCH 10/18] ipu3-cio2: Rename ipu3-cio2.c to allow module to be built from multiple source files retaining ipu3-cio2 name Daniel Scally
2020-12-01  6:56   ` Bingbu Cao
2020-12-01  7:07     ` Bingbu Cao
2020-11-30 13:31 ` [PATCH 11/18] media: v4l2-core: v4l2-async: Check possible match in match_fwnode based on sd->fwnode->secondary Daniel Scally
2020-11-30 16:27   ` Laurent Pinchart
2020-11-30 17:55   ` Andy Shevchenko
2020-11-30 13:31 ` [PATCH 12/18] acpi: Add acpi_dev_get_next_match_dev() and macro to iterate through acpi_devices matching a given _HID Daniel Scally
2020-11-30 17:58   ` Andy Shevchenko
2020-11-30 13:31 ` [PATCH 13/18] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows Daniel Scally
2020-11-30 16:45   ` kernel test robot
2020-11-30 17:09   ` Laurent Pinchart
2020-11-30 18:14     ` Andy Shevchenko
2020-12-01 22:08     ` Dan Scally
2020-12-01 22:11       ` Dan Scally
2020-12-01 22:30       ` Laurent Pinchart
2020-12-01 23:15         ` Dan Scally
2020-12-02 10:38         ` Sakari Ailus
2020-12-02 10:53           ` Dan Scally
2020-12-02 12:02             ` Andy Shevchenko
2020-12-02 22:44               ` Dan Scally
2020-12-02 12:01           ` Andy Shevchenko
2020-11-30 20:27   ` kernel test robot
2020-11-30 20:35   ` Sakari Ailus
2020-12-01  8:13     ` Dan Scally
2020-12-01 15:06     ` Andy Shevchenko
2020-12-15 10:28     ` Daniel Scally
2020-12-15 10:32       ` Daniel Scally
2020-12-15 22:02       ` Sakari Ailus
2020-12-17 14:17         ` Daniel Scally
2020-11-30 13:31 ` [PATCH 14/18] acpi: utils: Add function to fetch dependent acpi_devices Daniel Scally
2020-11-30 18:23   ` Andy Shevchenko
2020-11-30 18:40     ` Laurent Pinchart
2020-11-30 23:54     ` Dan Scally
2020-12-01 15:10       ` Andy Shevchenko
2020-12-01 15:23         ` Dan Scally
2020-11-30 13:31 ` [PATCH 15/18] i2c: i2c-core-acpi: Add i2c_acpi_dev_name() Daniel Scally
2020-11-30 17:11   ` Laurent Pinchart
2020-12-02 22:44     ` Dan Scally
2020-11-30 13:31 ` [PATCH 16/18] i2c: i2c-core-base: Use the new i2c_acpi_dev_name() in i2c_set_dev_name() Daniel Scally
2020-11-30 17:12   ` Laurent Pinchart
2020-11-30 19:18     ` Andy Shevchenko
2020-12-02  9:35       ` Andy Shevchenko
2020-12-02  9:49         ` Dan Scally
2020-12-01 23:50     ` Dan Scally
2020-11-30 13:31 ` [PATCH 17/18] gpio: gpiolib-acpi: Export acpi_get_gpiod() Daniel Scally
2020-11-30 17:02   ` kernel test robot
2020-11-30 18:04   ` kernel test robot
2020-11-30 19:20   ` Andy Shevchenko
2020-11-30 13:31 ` [PATCH 18/18] ipu3: Add driver for dummy INT3472 ACPI device Daniel Scally
2020-11-30 16:17   ` Jean-Michel Hautbois
2020-11-30 23:20     ` Dan Scally
2020-12-01 18:31       ` Andy Shevchenko
2020-12-01 18:36         ` Laurent Pinchart
2020-12-01 18:51           ` Andy Shevchenko
2020-11-30 16:29   ` Kieran Bingham
2020-11-30 17:21     ` Laurent Pinchart
2020-11-30 20:07   ` Andy Shevchenko
2020-11-30 23:32     ` Laurent Pinchart
2020-12-01 15:55       ` Sakari Ailus
2020-12-01 18:37         ` Laurent Pinchart
2020-12-02 11:09           ` Sakari Ailus
2020-12-02 12:42             ` Laurent Pinchart
2020-12-02 15:08               ` Andy Shevchenko
2020-12-03 12:37                 ` Dan Scally
2020-12-03 12:57                   ` Andy Shevchenko
2020-12-01 18:49       ` Andy Shevchenko
2020-12-01 20:59         ` Dan Scally
2020-12-02  9:39           ` Andy Shevchenko
2020-12-02 12:35             ` Laurent Pinchart
2020-12-02 15:11               ` Andy Shevchenko
2020-12-03 12:25             ` Dan Scally
2020-12-13 22:48         ` Daniel Scally
2020-12-14 15:33           ` Andy Shevchenko
2020-12-01  8:30     ` Dan Scally
2020-12-01 18:54       ` Andy Shevchenko
2020-12-01 18:55         ` Laurent Pinchart
2020-12-01 19:05           ` Andy Shevchenko
2020-12-01 19:06             ` Laurent Pinchart
2020-12-01 19:21               ` Andy Shevchenko
2020-12-01 20:34                 ` Hans de Goede
2020-12-01 20:46                   ` Andy Shevchenko
2020-12-02 12:48                   ` Laurent Pinchart
2020-12-02 15:15                     ` Andy Shevchenko
2020-12-01 21:05                 ` Dan Scally
2020-12-02  9:42                   ` Andy Shevchenko
2021-01-07 23:55     ` Daniel Scally
2021-01-08 12:17       ` Andy Shevchenko
2021-01-08 23:24         ` Daniel Scally
     [not found]           ` <CAHp75Vcy878xKUUUDH5ory9uS-Vhhx_W1PZc=S6hsSLYJ0i60w@mail.gmail.com>
2021-01-09  9:58             ` Daniel Scally
2021-01-09  0:18         ` Laurent Pinchart
2021-01-09  0:39           ` Daniel Scally
2020-11-30 20:52   ` Sakari Ailus
2020-11-30 23:06     ` Dan Scally [this message]
2020-11-30 23:21       ` Laurent Pinchart
2020-12-01  0:05         ` Dan Scally
2020-12-01  6:44       ` Sakari Ailus
2020-12-01  8:08         ` Dan Scally
2020-12-01  8:09           ` Dan Scally
2020-12-01 12:32           ` Sakari Ailus
2020-12-01 12:40             ` Laurent Pinchart
2020-12-01 12:44               ` Sakari Ailus
2020-12-01 12:48             ` Dan Scally
2020-12-01 19:01               ` Andy Shevchenko
2020-12-01 18:55       ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3e8494a0-a2c0-59e7-46bb-9635c3c239dd@gmail.com \
    --to=djrscally@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=bingbu.cao@intel.com \
    --cc=devel@acpica.org \
    --cc=erik.kaneda@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=jacopo+renesas@jmondi.org \
    --cc=jorhand@linux.microsoft.com \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=kitakar@gmail.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lenb@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mchehab@kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=pmladek@suse.com \
    --cc=rjw@rjwysocki.net \
    --cc=robert.moore@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=sakari.ailus@iki.fi \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tian.shu.qiu@intel.com \
    --cc=wsa@kernel.org \
    --cc=yong.zhi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).