From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: "Lucas De Marchi" <lucas.demarchi@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Jarkko Nikula" <jarkko.nikula@linux.intel.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Jan Dabros" <jsd@semihalf.com>,
"Andi Shyti" <andi.shyti@kernel.org>,
"Raag Jadav" <raag.jadav@intel.com>,
"Tauro, Riana" <riana.tauro@intel.com>,
"Adatrao, Srinivasa" <srinivasa.adatrao@intel.com>,
"Michael J. Ruhl" <michael.j.ruhl@intel.com>,
intel-xe@lists.freedesktop.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/4] drm/xe: Support for I2C attached MCUs
Date: Thu, 26 Jun 2025 17:21:02 +0300 [thread overview]
Message-ID: <aF1XTr2y1EmkRT_8@smile.fi.intel.com> (raw)
In-Reply-To: <20250626135610.299943-3-heikki.krogerus@linux.intel.com>
On Thu, Jun 26, 2025 at 04:56:07PM +0300, Heikki Krogerus wrote:
> Adding adaption/glue layer where the I2C host adapter
> (Synopsys DesignWare I2C adapter) and the I2C clients (the
> microcontroller units) are enumerated.
>
> The microcontroller units (MCU) that are attached to the GPU
> depend on the OEM. The initially supported MCU will be the
> Add-In Management Controller (AMC).
...
> +static int xe_i2c_register_adapter(struct xe_i2c *i2c)
> +{
> + struct pci_dev *pci = to_pci_dev(i2c->drm_dev);
> + struct platform_device *pdev;
> + struct fwnode_handle *fwnode;
> + int ret;
> +
> + fwnode = fwnode_create_software_node(xe_i2c_adapter_properties, NULL);
> + if (!fwnode)
> + return -ENOMEM;
> +
> + /*
> + * Not using platform_device_register_full() here because we don't have
> + * a handle to the platform_device before it returns. xe_i2c_notifier()
> + * uses that handle, but it may be called before
> + * platform_device_register_full() is done.
> + */
> + pdev = platform_device_alloc(adapter_name, pci_dev_id(pci));
> + if (!pdev) {
> + ret = -ENOMEM;
> + goto err_fwnode_remove;
> + }
> +
> + if (i2c->adapter_irq) {
> + struct resource res = { };
> +
> + res.start = i2c->adapter_irq;
> + res.name = "xe_i2c";
> + res.flags = IORESOURCE_IRQ;
struct resource res;
res = DEFINE_RES_IRQ_NAMED(i2c->adapter_irq, "xe_i2c");
> + ret = platform_device_add_resources(pdev, &res, 1);
> + if (ret)
> + goto err_pdev_put;
> + }
> +
> + pdev->dev.parent = i2c->drm_dev;
> + pdev->dev.fwnode = fwnode;
> + i2c->adapter_node = fwnode;
> + i2c->pdev = pdev;
> +
> + ret = platform_device_add(pdev);
> + if (ret)
> + goto err_pdev_put;
> +
> + return 0;
> +
> +err_pdev_put:
> + platform_device_put(pdev);
> +err_fwnode_remove:
> + fwnode_remove_software_node(fwnode);
> +
> + return ret;
> +}
...
> +static int xe_i2c_irq_map(struct irq_domain *h, unsigned int virq,
> + irq_hw_number_t hw_irq_num)
> +{
> + irq_set_chip_and_handler(virq, &dummy_irq_chip, handle_simple_irq);
Wondering if you need to setup a custom lockdep class here.
> + return 0;
> +}
...
> +static void xe_i2c_remove_irq(struct xe_i2c *i2c)
> +{
> + if (i2c->irqdomain) {
if (!i2c->irqdomain)
return;
> + irq_dispose_mapping(i2c->adapter_irq);
> + irq_domain_remove(i2c->irqdomain);
> + }
> +}
...
> +static void xe_i2c_remove(void *data)
> +{
> + struct xe_i2c *i2c = data;
> + int i;
unsigned?
> + for (i = 0; i < XE_I2C_MAX_CLIENTS; i++)
> + i2c_unregister_device(i2c->client[i]);
> +
> + bus_unregister_notifier(&i2c_bus_type, &i2c->bus_notifier);
> + xe_i2c_unregister_adapter(i2c);
> + xe_i2c_remove_irq(i2c);
> +}
...
> +int xe_i2c_probe(struct xe_device *xe)
> +{
> + struct xe_i2c_endpoint ep;
> + struct regmap *regmap;
> + struct xe_i2c *i2c;
> + int ret;
> +
> + xe_i2c_read_endpoint(xe_root_tile_mmio(xe), &ep);
> + if (ep.cookie != XE_I2C_EP_COOKIE_DEVICE)
> + return 0;
> +
> + i2c = devm_kzalloc(xe->drm.dev, sizeof(*i2c), GFP_KERNEL);
> + if (!i2c)
> + return -ENOMEM;
> +
> + INIT_WORK(&i2c->work, xe_i2c_client_work);
> + i2c->mmio = xe_root_tile_mmio(xe);
> + i2c->drm_dev = xe->drm.dev;
> + i2c->ep = ep;
> + regmap = devm_regmap_init(i2c->drm_dev, NULL, i2c, &i2c_regmap_config);
Use of i2c->drm_dev makes harder to maintain and understand the code.
Managed resources should be carefully attached to the correct device,
otherwise it's inevitable object lifetime related issues.
With
struct device *dev = xe->drm.dev;
and using local dev, it becomes easier to get and avoid such subtle mistakes.
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + i2c->bus_notifier.notifier_call = xe_i2c_notifier;
> + ret = bus_register_notifier(&i2c_bus_type, &i2c->bus_notifier);
> + if (ret)
> + return ret;
> +
> + ret = xe_i2c_create_irq(i2c);
> + if (ret)
> + goto err_unregister_notifier;
> +
> + ret = xe_i2c_register_adapter(i2c);
> + if (ret)
> + goto err_remove_irq;
> +
> + return devm_add_action_or_reset(i2c->drm_dev, xe_i2c_remove, i2c);
> +
> +err_remove_irq:
> + xe_i2c_remove_irq(i2c);
> +
> +err_unregister_notifier:
> + bus_unregister_notifier(&i2c_bus_type, &i2c->bus_notifier);
> +
> + return ret;
> +}
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-06-26 14:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 13:56 [PATCH v4 0/4] drm/xe: i2c support Heikki Krogerus
2025-06-26 13:56 ` [PATCH v4 1/4] i2c: designware: Add quirk for Intel Xe Heikki Krogerus
2025-06-26 13:56 ` [PATCH v4 2/4] drm/xe: Support for I2C attached MCUs Heikki Krogerus
2025-06-26 14:21 ` Andy Shevchenko [this message]
2025-06-27 8:56 ` Heikki Krogerus
2025-06-27 11:16 ` Andy Shevchenko
2025-06-26 13:56 ` [PATCH v4 3/4] drm/xe/pm: Wire up suspend/resume for I2C controller Heikki Krogerus
2025-06-27 12:45 ` Raag Jadav
2025-06-27 12:58 ` Heikki Krogerus
2025-06-27 13:15 ` Raag Jadav
2025-06-26 13:56 ` [PATCH v4 4/4] drm/xe/xe_i2c: Add support for i2c in survivability mode Heikki Krogerus
2025-06-26 14:24 ` Andy Shevchenko
2025-06-27 10:36 ` Heikki Krogerus
2025-06-26 15:46 ` ✗ CI.checkpatch: warning for drm/xe: i2c support (rev4) Patchwork
2025-06-26 15:48 ` ✓ CI.KUnit: success " Patchwork
2025-06-26 16:38 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-06-30 17:55 ` ✗ Xe.CI.Full: " Patchwork
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=aF1XTr2y1EmkRT_8@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=airlied@gmail.com \
--cc=andi.shyti@kernel.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jarkko.nikula@linux.intel.com \
--cc=jsd@semihalf.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=michael.j.ruhl@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=raag.jadav@intel.com \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=srinivasa.adatrao@intel.com \
--cc=thomas.hellstrom@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.