Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list
To:     Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Hans de Goede <hdegoede@redhat.com>
Cc:     Mark Brown <broonie@kernel.org>, 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>
References: <20210824230620.1003828-1-djrscally@gmail.com>
 <20210824230620.1003828-2-djrscally@gmail.com>
 <20210825103301.GC5186@sirena.org.uk>
 <cc65098e-b459-b20a-f6e2-ee521fc20ca7@redhat.com>
 <20210825152735.GJ5186@sirena.org.uk>
 <YSZk5tyAxZoosXS3@pendragon.ideasonboard.com>
 <a5421695-803a-52fd-ea2e-edd9ef548892@redhat.com>
 <YSaq1R6kp6tYeRAJ@pendragon.ideasonboard.com>
From:   Daniel Scally <djrscally@gmail.com>
Message-ID: <a71a448f-3782-93f1-fb1d-0334db8df5a8@gmail.com>
Date:   Wed, 25 Aug 2021 22:24:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <YSaq1R6kp6tYeRAJ@pendragon.ideasonboard.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 25/08/2021 21:40, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Wed, Aug 25, 2021 at 10:25:23PM +0200, Hans de Goede wrote:
>> 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.
> 
> If the GPIOs are also hooked up to the TPS68470 and not to GPIOs of the
> SoC, then I suppose that would be fine in this case.

The GPIOs that we're translating into clks / mapping to the sensors in
the INT3472 code are SOC GPIOs actually...this is the first bit of code
that relates to a physical TPS68470.
> 
> Do you have any plan to work on IPU4 support ? ;-)
> 
>> *) IPU4 also used the INT3472 ACPI devices and what we have for discrete
>> IO devices seems to match.
>