public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	linux-acpi@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
Date: Thu, 6 Dec 2018 09:53:15 +0100	[thread overview]
Message-ID: <a4df490c-27da-900d-f91f-0facfa97445f@redhat.com> (raw)
In-Reply-To: <20181205212532.GV9144@intel.com>

Hi Ville,

Thank you for the review.

On 05-12-18 22:25, Ville Syrjälä wrote:
> On Wed, Dec 05, 2018 at 10:03:09PM +0100, Hans de Goede wrote:
>> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
>> PMIC.
>>
>> On some CHT devices this fixes the LCD panel not lighting up when it was
>> not initialized by the GOP, because an external monitor was plugged in and
>> the GOP initialized only the external monitor.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>>   drivers/acpi/pmic/intel_pmic_chtwc.c | 23 +++++++++++++++++++++++
>>   1 file changed, 23 insertions(+)
>>
>> diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c b/drivers/acpi/pmic/intel_pmic_chtwc.c
>> index 078b0448f30a..d035541f0ed2 100644
>> --- a/drivers/acpi/pmic/intel_pmic_chtwc.c
>> +++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
>> @@ -12,6 +12,7 @@
>>   #include <linux/mfd/intel_soc_pmic.h>
>>   #include <linux/platform_device.h>
>>   #include <linux/regmap.h>
>> +#include <asm/unaligned.h>
>>   #include "intel_pmic.h"
>>   
>>   #define CHT_WC_V1P05A_CTRL		0x6e3b
>> @@ -231,6 +232,27 @@ static int intel_cht_wc_pmic_update_power(struct regmap *regmap, int reg,
>>   	return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
>>   }
>>   
>> +static void intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
>> +						    const u8 *data)
>> +{
>> +	u16 i2c_client_address, reg_address, address;
>> +	u32 value, mask;
>> +
>> +	i2c_client_address	= get_unaligned_be16(data);
>> +	reg_address		= get_unaligned_be16(data + 2);
>> +	value			= get_unaligned_be32(data + 4);
>> +	mask			= get_unaligned_be32(data + 8);
> 
> This doesn't match the docs:

Well I didn't have access to the docs, I just looked at the
data and interpreted that, the first byte being reserved
for future use tripped me up.

> "Byte0 – PMIC Flag
>   Bits 7:0 = Reserved for future use
> 
>   Byte2,1 – PMIC Slave Address
>   Bits 15:0 = Slave address for PMIC access
>   Each slave can address 256byte register space in general
> 
>   Bytes 6,5,4,3 – DWORD 0
>   Bits 31:0 = PMIC Register Address
> 
>   Bytes 10,9,8,7 – DWORD 1
>   Bits 31:0 = PMIC Register Data
> 
>   Bytes 14,13,12,11 – DWORD 2
>   Bits 31:0 = PMIC Register DataMask"
> 
> Though I wouldn't be entirely surprised if the docs are simply
> wrong.

I think the docs are probably right, of the 2 sequences I'm seeing
the OFF sequence has more 00 bytes, so the ON sequence is the most
interesting, this is:

00 6e 00 3c 00 00 00 01 00 00 00 01 00 00 00

With my (big endian) interpretation that gives:

PMIC Slave Address       00 6e
PMIC Register Address    00 3c
PMIC Register Data       00 00 00 01
PMIC Register Mask       00 00 00 01

With the docs slightly shifted (little endian) interpretation that gives:

Reserverd                00
PMIC Slave Address       00 6e
PMIC Register Address    00 00 00 3c
PMIC Register Data       00 00 00 01
PMIC Register Mask       00 00 00 01

So the 2 interpretation agree for the data which I'm actually
seeing used and the docs interpretation actually consumes all bytes.

I'll prepare a v2 of this patch-set using the docs interpretation
of the bytes.

Regards,

Hans





> 
>> +
>> +	if ((i2c_client_address & 0xff00) || (reg_address & 0xff00)) {
>> +		pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
>> +			__func__, i2c_client_address, reg_address);
>> +		return;
>> +	}
>> +
>> +	address = (i2c_client_address << 8) | reg_address;
>> +	regmap_update_bits(regmap, address, mask, value);
>> +}
>> +
>>   /*
>>    * The thermal table and ops are empty, we do not support the Thermal opregion
>>    * (DPTF) due to lacking documentation.
>> @@ -238,6 +260,7 @@ static int intel_cht_wc_pmic_update_power(struct regmap *regmap, int reg,
>>   static struct intel_pmic_opregion_data intel_cht_wc_pmic_opregion_data = {
>>   	.get_power		= intel_cht_wc_pmic_get_power,
>>   	.update_power		= intel_cht_wc_pmic_update_power,
>> +	.exec_mipi_pmic_seq_element = intel_cht_wc_exec_mipi_pmic_seq_element,
>>   	.power_table		= power_table,
>>   	.power_table_count	= ARRAY_SIZE(power_table),
>>   };
>> -- 
>> 2.19.2
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-12-06  8:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-05 21:03 [PATCH 0/3] ACPI-PMIC + i915: Add support for PMIC MIPI sequences Hans de Goede
2018-12-05 21:03 ` [PATCH 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements Hans de Goede
2018-12-05 21:03 ` [PATCH 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC Hans de Goede
2018-12-05 21:25   ` Ville Syrjälä
2018-12-06  8:53     ` Hans de Goede [this message]
2018-12-05 21:03 ` [PATCH 3/3] drm/i915/intel_dsi_vbt: Add support for PMIC mipi sequences 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=a4df490c-27da-900d-f91f-0facfa97445f@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=rodrigo.vivi@intel.com \
    --cc=ville.syrjala@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox