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. >
