Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list

From: Hans de Goede <hdegoede@redhat.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Mark Brown <broonie@kernel.org>
Cc: Daniel Scally <djrscally@gmail.com>,
	linux-kernel@vger.kernel.org,
	platform-driver-x86@vger.kernel.org,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Gross <mgross@linux.intel.com>,
	Maximilian Luz <luzmaximilian@gmail.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	Sakari Ailus <sakari.ailus@iki.fi>
Subject: Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list
Date: Wed, 25 Aug 2021 22:25:23 +0200	[thread overview]
Message-ID: <a5421695-803a-52fd-ea2e-edd9ef548892@redhat.com> (raw)
In-Reply-To: <YSZk5tyAxZoosXS3@pendragon.ideasonboard.com>

Hi,

On 8/25/21 5:42 PM, Laurent Pinchart wrote:
> On Wed, Aug 25, 2021 at 04:27:35PM +0100, Mark Brown wrote:
>> On Wed, Aug 25, 2021 at 04:48:15PM +0200, Hans de Goede wrote:
>>
>>> Daniel, I believe that what Mark wants here is something similar to what
>>> we already do for the 5v boost converter regulator in the TI bq24190 charger
>>> chip used on some Cherry Trail devices.
>>
>> Yeah, that or something like a generalized version of it which lets a
>> separate quirk file like they seem to have register the data to insert -
>> I'd be happy enough with the simple thing too given that it's not
>> visible to anything, or with DMI quirks in the regulator driver too for
>> that matter if it's just one or two platforms but there do seem to be
>> rather a lot of these platforms which need quirks.
> 
> Let's also remember that we have to handle not just regulators, but also
> GPIOs and clocks. And I'm pretty sure there will be more. We could have
> a mechanism specific to the tps68470 driver to pass platform data from
> the board file to the driver, and replicate that mechanism in different
> drivers (for other regulators, clocks and GPIOs), but I really would
> like to avoid splitting the DMI-conditioned platform data in those
> drivers directly. I'd like to store all the init data for a given
> platform in a single "board" file.

I agree, but so far all the handling for clks/gpios for IPU3 (+ IPU4 (*))
laptops is done in the drivers/platform/x86/intel/int3472 code and the
passing of platform_data with regulator init-data would also happen in
the mfd-cell instantiation code living there. IOW if we just go with
that then we will already have everything in one place. At least
for the IPU3 case.

Regards,

Hans

*) IPU4 also used the INT3472 ACPI devices and what we have for discrete
IO devices seems to match.