All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Mark Brown <broonie@kernel.org>
Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Mark Gross <markgross@kernel.org>,
	Andy Shevchenko <andy@infradead.org>,
	Daniel Scally <djrscally@gmail.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Len Brown <lenb@kernel.org>,
	linux-acpi@vger.kernel.org, platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Kate Hsuan <hpa@redhat.com>,
	linux-media@vger.kernel.org, linux-clk@vger.kernel.org
Subject: Re: [PATCH 05/12] regulator: Introduce tps68470-regulator driver
Date: Mon, 11 Oct 2021 13:43:40 +0200	[thread overview]
Message-ID: <f6f2d7e8-fdb8-ed64-0cdd-65aded9fc42c@redhat.com> (raw)
In-Reply-To: <YWQU/SYTT5Vk24XH@sirena.org.uk>

Hi,

On 10/11/21 12:42 PM, Mark Brown wrote:
> On Fri, Oct 08, 2021 at 06:21:14PM +0200, Hans de Goede wrote:
> 
>> +++ b/drivers/regulator/tps68470-regulator.c
>> @@ -0,0 +1,194 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Regulator driver for TPS68470 PMIC
>> + *
> 
> Please make the entire comment a C++ one so things look more
> intentional.

Ok, will do so for the next version.


>> +
>> +/*
>> + * The ACPI tps68470 probe-ordering depends on the clk/gpio/regulator drivers
>> + * being registered before the MFD cells are created (the MFD driver calls
>> + * acpi_dev_clear_dependencies() after the cell creation).
>> + * subsys_initcall() ensures this when the drivers are builtin.
>> + */
>> +static int __init tps68470_regulator_init(void)
>> +{
>> +	return platform_driver_register(&tps68470_regulator_driver);
>> +}
>> +subsys_initcall(tps68470_regulator_init);
> 
> If this is actually required then the driver is broken for modular use
> which frankly is just generally broken.  I don't understand why this
> driver would require this when other drivers don't, or what the actual
> requirement is here - what does the call do and why is the ordering
> important?

For the camera-sensor which is a consumer of this devices to be able
to get the regulators (and not end up with a dummy regulator) the
consumer info added through the constraints passed as platform data
must be available to the regulator framework before the sensor-driver's
probe() method tries to get the regulators.

The ACPI fwnode describing the sensor has an ACPI _DEP dependency on
the ACPI fwnode describing the PMIC. To ensure that the PMIC driver
binds first patches 1 + 2 of this series make the ACPI code use this
dependency to not instantiate the i2c-client for the sensor until
the PMIC driver has bound.

The PMIC driver is a MFD driver creating GPIO, clk and regulator
MFD cells. So in order for the ACPI code delaying the instantiation
to help, the regulator constraints / consumer info must be registered
when the MFD driver is done binding. This means that the regulator
driver for the regulator MFD cells must be registered before the
platform_dev-s for the cell is instantiated, so that the driver
binds immediately (during instantiation) and thus the regulator
consumer info is available before the PMIC-MFD-driver's probe()
method is done.

The use of a subsys_initcall() here ensures that when builtin
the regulator driver is registered before the PMIC-MFD-driver
is registered (the PMIC driver uses a normal device_initcall).

To make this work when everything is build as a module patch 12/12
adds the following to the PMIC-MFD-driver:

MODULE_SOFTDEP("pre: clk-tps68470 tps68470-regulator");

This will make modprobe load the clk and regulator drivers
before it loads the main/MFD tps68470 driver.

I've tested this with everything built as module (the typical
setup for standard x86 setups) and without the MODULE_SOFTDEP
the sensor driver ends up with a dummy regulator (illustrating
the problem) and with the SOFTDEP in place everything works
as it should.

I hope this helps explain things.

Regards,

Hans


  reply	other threads:[~2021-10-11 11:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-08 16:21 [PATCH 00/12] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
2021-10-08 16:21 ` [PATCH 01/12] ACPI: Add has_unmet_acpi_deps() helper function Hans de Goede
2021-10-08 16:21 ` [PATCH 02/12] media: i2c: ov8865: Add an has_unmet_acpi_deps() check Hans de Goede
2021-10-08 18:41   ` Laurent Pinchart
2021-10-08 18:48     ` Hans de Goede
2021-10-08 18:58       ` Laurent Pinchart
2021-10-09 15:31         ` Hans de Goede
2021-10-08 16:21 ` [PATCH 03/12] media: i2c: ov5693: " Hans de Goede
2021-10-08 16:21 ` [PATCH 04/12] platform_data: Add linux/platform_data/tps68470.h file Hans de Goede
2021-10-08 16:21 ` [PATCH 05/12] regulator: Introduce tps68470-regulator driver Hans de Goede
2021-10-11 10:42   ` Mark Brown
2021-10-11 11:43     ` Hans de Goede [this message]
2021-10-15 16:46       ` Mark Brown
2021-10-15 18:50         ` Hans de Goede
2021-10-15 18:58           ` Mark Brown
2021-10-15 19:27             ` Hans de Goede
2021-10-15 19:40               ` Mark Brown
2021-10-15 19:48                 ` Hans de Goede
2021-10-15 19:59                   ` Mark Brown
2021-10-15 20:14                     ` Hans de Goede
2021-10-15 22:29                       ` Mark Brown
2021-10-16 10:18                         ` Hans de Goede
2021-10-08 16:21 ` [PATCH 06/12] clk: Introduce clk-tps68470 driver Hans de Goede
2021-10-08 16:21 ` [PATCH 07/12] platform/x86: int3472: Enable I2c daisy chain Hans de Goede
2021-10-08 16:21 ` [PATCH 08/12] platform/x86: int3472: Split into 2 drivers Hans de Goede
2021-10-08 16:21 ` [PATCH 09/12] platform/x86: int3472: Add get_sensor_adev_and_name() helper Hans de Goede
2021-10-08 16:21 ` [PATCH 10/12] platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell Hans de Goede
2021-10-08 16:21 ` [PATCH 11/12] platform/x86: int3472: Pass tps68470_regulator_platform_data " Hans de Goede
2021-10-08 16:21 ` [PATCH 12/12] platform/x86: int3472: Call acpi_dev_clear_dependencies() on successful probe Hans de Goede

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=f6f2d7e8-fdb8-ed64-0cdd-65aded9fc42c@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andy@infradead.org \
    --cc=broonie@kernel.org \
    --cc=djrscally@gmail.com \
    --cc=hpa@redhat.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lenb@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=markgross@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sboyd@kernel.org \
    /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.