| Message ID | 20211030182813.116672-3-hdegoede@redhat.com |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | power-suppy/i2c/extcon: Add support for cht-wc PMIC without USB-PD support | expand |
On Sat, Oct 30, 2021 at 9:28 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Add a new "intel,cht-wc-setup" string property to the "INT34D3:00" > i2c_client for the Whiskey Cove PMIC found on several Cherry Trail > based devices. At least 3 setups are known: > > 1. The WC PMIC is connected to a TI BQ24292i charger, paired with > a Maxim MAX17047 fuelgauge + a FUSB302 USB Type-C Controller + > a PI3USB30532 USB switch, for a fully functional Type-C port > > 2. The WC PMIC is connected to a TI BQ25890 charger, paired with > a TI BQ27520 fuelgauge, for a USB-2 only Type-C port without PD > > 3. The WC PMIC is connected to a TI BQ25890 charger, paired with > a TI BQ27542 fuelgauge, for a micro-USB port > > Which setup is in use cannot be determined reliably from the ACPI tables > and various drivers (extcon-intel-cht-wc.c, i2c-cht-wc.c, ...) need > to know which setup they are dealing with. If it's internal property only, I would rather expect it to start with 'linux,' as DWC3 does. And it's also USB related. ... > + PROPERTY_ENTRY_STRING("intel,cht-wc-setup", "bq24292i,max17047,fusb302,pi3usb30532"), > + PROPERTY_ENTRY_STRING("intel,cht-wc-setup", "bq25890,bq27520"), Besides that I'm not sure about the name of the property, maybe 'linux,cht-wc-usb-chips' or alike? And since it's a list, can we make it a string array?
Hi Andy, Thank you for your feedback. On 10/30/21 23:56, Andy Shevchenko wrote: > On Sat, Oct 30, 2021 at 9:28 PM Hans de Goede <hdegoede@redhat.com> wrote: >> >> Add a new "intel,cht-wc-setup" string property to the "INT34D3:00" >> i2c_client for the Whiskey Cove PMIC found on several Cherry Trail >> based devices. At least 3 setups are known: >> >> 1. The WC PMIC is connected to a TI BQ24292i charger, paired with >> a Maxim MAX17047 fuelgauge + a FUSB302 USB Type-C Controller + >> a PI3USB30532 USB switch, for a fully functional Type-C port >> >> 2. The WC PMIC is connected to a TI BQ25890 charger, paired with >> a TI BQ27520 fuelgauge, for a USB-2 only Type-C port without PD >> >> 3. The WC PMIC is connected to a TI BQ25890 charger, paired with >> a TI BQ27542 fuelgauge, for a micro-USB port >> >> Which setup is in use cannot be determined reliably from the ACPI tables >> and various drivers (extcon-intel-cht-wc.c, i2c-cht-wc.c, ...) need >> to know which setup they are dealing with. > > If it's internal property only, I would rather expect it to start with > 'linux,' as DWC3 does. And it's also USB related. > > ... > >> + PROPERTY_ENTRY_STRING("intel,cht-wc-setup", "bq24292i,max17047,fusb302,pi3usb30532"), > >> + PROPERTY_ENTRY_STRING("intel,cht-wc-setup", "bq25890,bq27520"), > > Besides that I'm not sure about the name of the property, maybe > 'linux,cht-wc-usb-chips' or alike? And since it's a list, can we make > it a string array? > So now that I also have a yogabook to test on it has become clear that we really need to treat each device-model/board with a cht-wc PMIC differently in the various cht-wc MFD cell drivers. So instead of using device-properties (patch 1 + 2 from this series) I've chosen to add a intel_cht_wc_get_model( helper to: drivers/mfd/intel_soc_pmic_chtwc.c Which uses DMI matching (in a shared place so that we need the DMI table only once) and returns an enum value which represents all known boards. Regards, Hans
diff --git a/drivers/platform/x86/dmi_device_properties.c b/drivers/platform/x86/dmi_device_properties.c index 1bcd14a0bc78..bd973afbde5f 100644 --- a/drivers/platform/x86/dmi_device_properties.c +++ b/drivers/platform/x86/dmi_device_properties.c @@ -387,6 +387,16 @@ static const struct ts_dmi_data gp_electronic_t701_data = { .properties = gp_electronic_t701_props, }; +static const struct property_entry gpd_win_pocket_props[] = { + PROPERTY_ENTRY_STRING("intel,cht-wc-setup", "bq24292i,max17047,fusb302,pi3usb30532"), + { } +}; + +static const struct ts_dmi_data gpd_win_pocket_data = { + .acpi_name = "INT34D3:00", + .properties = gpd_win_pocket_props, +}; + static const struct property_entry irbis_tw90_props[] = { PROPERTY_ENTRY_U32("touchscreen-size-x", 1720), PROPERTY_ENTRY_U32("touchscreen-size-y", 1138), @@ -978,6 +988,16 @@ static const struct ts_dmi_data vinga_twizzle_j116_data = { .properties = vinga_twizzle_j116_props, }; +static const struct property_entry xiaomi_mi_pad2_props[] = { + PROPERTY_ENTRY_STRING("intel,cht-wc-setup", "bq25890,bq27520"), + { } +}; + +static const struct ts_dmi_data xiaomi_mi_pad2_data = { + .acpi_name = "INT34D3:00", + .properties = xiaomi_mi_pad2_props, +}; + /* NOTE: Please keep this table sorted alphabetically */ const struct dmi_system_id dmi_device_properties[] = { { @@ -1166,6 +1186,24 @@ const struct dmi_system_id dmi_device_properties[] = { DMI_MATCH(DMI_BIOS_VERSION, "itWORKS.G.WI71C.JGBMRB"), }, }, + { + /* GPD win / GPD pocket mini laptops */ + .driver_data = (void *)&gpd_win_pocket_data, + /* + * Note this may not seem like a very unique match, but in the + * 24000+ DMI decode dumps from linux-hardware.org only 42 have + * a board_vendor value of "AMI Corporation" and of those 42 + * only 1 (the GPD win/pocket entry) has a board_name of + * "Default string". Also few devices have both board_ and + * product_name not set. + */ + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"), + DMI_MATCH(DMI_BOARD_NAME, "Default string"), + DMI_MATCH(DMI_BOARD_SERIAL, "Default string"), + DMI_MATCH(DMI_PRODUCT_NAME, "Default string"), + }, + }, { /* Irbis TW90 */ .driver_data = (void *)&irbis_tw90_data, @@ -1578,6 +1616,14 @@ const struct dmi_system_id dmi_device_properties[] = { DMI_MATCH(DMI_PRODUCT_NAME, "TW700") }, }, + { + /* Xiaomi Mi Pad 2 */ + .driver_data = (void *)&xiaomi_mi_pad2_data, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Xiaomi Inc"), + DMI_MATCH(DMI_PRODUCT_NAME, "Mipad2"), + }, + }, { /* Yours Y8W81, same case and touchscreen as Chuwi Vi8 */ .driver_data = (void *)&chuwi_vi8_data,
Add a new "intel,cht-wc-setup" string property to the "INT34D3:00" i2c_client for the Whiskey Cove PMIC found on several Cherry Trail based devices. At least 3 setups are known: 1. The WC PMIC is connected to a TI BQ24292i charger, paired with a Maxim MAX17047 fuelgauge + a FUSB302 USB Type-C Controller + a PI3USB30532 USB switch, for a fully functional Type-C port 2. The WC PMIC is connected to a TI BQ25890 charger, paired with a TI BQ27520 fuelgauge, for a USB-2 only Type-C port without PD 3. The WC PMIC is connected to a TI BQ25890 charger, paired with a TI BQ27542 fuelgauge, for a micro-USB port Which setup is in use cannot be determined reliably from the ACPI tables and various drivers (extcon-intel-cht-wc.c, i2c-cht-wc.c, ...) need to know which setup they are dealing with. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/platform/x86/dmi_device_properties.c | 46 ++++++++++++++++++++ 1 file changed, 46 insertions(+)