[Intel-gfx] [PATCH v6 1/4] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
Hans de Goede
hdegoede at redhat.com
Tue Jan 8 13:40:22 UTC 2019
Hi,
On 07-01-19 16:35, Andy Shevchenko wrote:
> On Mon, Jan 07, 2019 at 12:15:53PM +0100, Hans de Goede wrote:
>> DSI LCD panels describe an initialization sequence in the Video BIOS
>> Tables using so called MIPI sequences. One possible element in these
>> sequences is a PMIC specific element of 15 bytes.
>>
>> Although this is not really an ACPI opregion, the ACPI opregion code is the
>> closest thing we have. We need to have support for these PMIC specific MIPI
>> sequence elements somwhere. Since we already instantiate a special platform
>> device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
>> with PMIC specific implementations of the OpRegion, the handling of MIPI
>> sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.
>>
>> This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
>> function, which is to be backed by a PMIC specific
>> exec_mipi_pmic_seq_element callback. This function will be called by the
>> i915 code to execture MIPI sequence PMIC elements.
>
>> +/**
>> + * intel_soc_pmic_exec_mipi_pmic_seq_element - Execute PMIC MIPI sequence
>
> I wonder if we need pmic duplication in the name.
Mipi sequences can do a bunch of things, talk to the panel over
the MIPI bus, set GPIOs, read-modify-write PMIC registers, etc.
This function can only execute the PMIC bits, not the rest,
so the second pmic is there to indiciate we are executing
a PMIC MIPI sequence and not e.g. a GPIO one. So I believe that
keeping this as is is best.
Regards,
Hans
>> + * @i2c_address: I2C client address for the PMIC
>> + * @reg_address: PMIC register address
>> + * @value: New value for the register bits to change
>> + * @mask: Mask indicating which register bits to change
>> + *
>> + * DSI LCD panels describe an initialization sequence in the i915 VBT (Video
>> + * BIOS Tables) using so called MIPI sequences. One possible element in these
>> + * sequences is a PMIC specific element of 15 bytes.
>> + *
>> + * This function executes these PMIC specific elements sending the embedded
>> + * commands to the PMIC.
>> + *
>> + * Return 0 on success, < 0 on failure.
>> + */
>> +int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32 reg_address,
>> + u32 value, u32 mask)
>> +{
>> + struct intel_pmic_opregion_data *d;
>> + int ret;
>> +
>> + if (!intel_pmic_opregion) {
>> + pr_warn("%s: No PMIC registered\n", __func__);
>> + return -ENXIO;
>> + }
>> +
>> + d = intel_pmic_opregion->data;
>> +
>> + mutex_lock(&intel_pmic_opregion->lock);
>> +
>> + if (d->exec_mipi_pmic_seq_element) {
>
>> + ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap,
>> + i2c_address, reg_address,
>> + value, mask);
>
> Here it's not quite a dup, but it's implied by the name of structure...
>
>> + } else {
>> + pr_warn("%s: Not implemented\n", __func__);
>> + pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask 0x%x\n",
>> + __func__, i2c_address, reg_address, value, mask);
>> + ret = -EOPNOTSUPP;
>> + }
>> +
>> + mutex_unlock(&intel_pmic_opregion->lock);
>> +
>> + return ret;
>> +}
>
More information about the Intel-gfx
mailing list