Re: [BISECTED] Suspend / USB broken on XPS 9370 + TB16

2019-10-07 Thread Carlo Caione

On 07/10/2019 09:13, Mathias Nyman wrote:

/cut

Does the below patch help?  Greg just applied it to his usb-linus branch.

ac343366846a xhci: Increase STS_SAVE timeout in xhci_suspend()
Link: 
https://lore.kernel.org/r/1570190373-30684-8-git-send-email-mathias.ny...@linux.intel.com 


Yes. That patch fixes the issue.

Thank you,

--
Carlo Caione


[BISECTED] Suspend / USB broken on XPS 9370 + TB16

2019-10-07 Thread Carlo Caione

Hi,
I bisected an issue down to commit f7fac17ca925 "xhci: Convert 
xhci_handshake() to use readl_poll_timeout_atomic()".


Setup:
XPS 9370 + Thunderbolt dock Dell TB16

Issue:
The laptop is unable to go to sleep. It never really goes to sleep and 
after a few seconds the USB dies.


Log:
https://termbin.com/icix

Cheers!

--
Carlo Caione


Re: [PATCH] net: phy: at803x: Use helpers to access MMD PHY registers

2019-01-25 Thread Carlo Caione

On 25/01/2019 15:00, Andrew Lunn wrote:

On Fri, Jan 25, 2019 at 12:35:10PM +, Carlo Caione wrote:

Libphy provides a standard set of helpers to access the MMD PHY
registers. Use those instead of relying on custom driver-specific
functions.


Hi Carlo


Hey Andrew,


Maybe deja vu, but i thought a similar patch went by recently?


uhm, not from me for sure. There is a discussion going on about similar 
stuff on the U-Boot ml, maybe you saw that?


Anyway, feel free to drop this if someone already fixed this.

Thanks,

--
Carlo Caione


[PATCH] net: phy: at803x: Use helpers to access MMD PHY registers

2019-01-25 Thread Carlo Caione
Libphy provides a standard set of helpers to access the MMD PHY
registers. Use those instead of relying on custom driver-specific
functions.

Signed-off-by: Carlo Caione 
---
 drivers/net/phy/at803x.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index f9432d053a22..23ba76f8d950 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -39,9 +39,6 @@
 #define AT803X_LOC_MAC_ADDR_0_15_OFFSET0x804C
 #define AT803X_LOC_MAC_ADDR_16_31_OFFSET   0x804B
 #define AT803X_LOC_MAC_ADDR_32_47_OFFSET   0x804A
-#define AT803X_MMD_ACCESS_CONTROL  0x0D
-#define AT803X_MMD_ACCESS_CONTROL_DATA 0x0E
-#define AT803X_FUNC_DATA   0x4003
 #define AT803X_REG_CHIP_CONFIG 0x1f
 #define AT803X_BT_BX_REG_SEL   0x8000
 
@@ -168,16 +165,9 @@ static int at803x_set_wol(struct phy_device *phydev,
if (!is_valid_ether_addr(mac))
return -EINVAL;
 
-   for (i = 0; i < 3; i++) {
-   phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
- AT803X_DEVICE_ADDR);
-   phy_write(phydev, AT803X_MMD_ACCESS_CONTROL_DATA,
- offsets[i]);
-   phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
- AT803X_FUNC_DATA);
-   phy_write(phydev, AT803X_MMD_ACCESS_CONTROL_DATA,
- mac[(i * 2) + 1] | (mac[(i * 2)] << 8));
-   }
+   for (i = 0; i < 3; i++)
+   phy_write_mmd(phydev, AT803X_DEVICE_ADDR, offsets[i],
+ mac[(i * 2) + 1] | (mac[(i * 2)] << 8));
 
value = phy_read(phydev, AT803X_INTR_ENABLE);
value |= AT803X_INTR_ENABLE_WOL;
-- 
2.19.1



Re: [PATCH] MAINTAINERS: Remove myself from the list

2018-12-04 Thread Carlo Caione
On Mon, 2018-12-03 at 11:21 +0100, Neil Armstrong wrote:
> On 01/12/2018 16:17, Carlo Caione wrote:
> > Kevin is basically doing all the work. Remove my name as co-
> > maintainer.
> 
> Sure, but couldn't we move you as reviewer and add Martin as reviewer
> aswell since he is dedicated to the Meson8X support ?
> 
> Or maybe add a separate entry with Kevin as maintainer and Martin as
> reviewer for Meson8X ?

This. At this point I don't think I will be going to work on the
Meson8X for a while and Martin proved to be the right guy for this job.

So, let's remove my name from here first and then Martin can add a new
entry for Meson8X.

Cheers,

--
Carlo Caione



Re: [PATCH] MAINTAINERS: Remove myself from the list

2018-12-04 Thread Carlo Caione
On Mon, 2018-12-03 at 11:21 +0100, Neil Armstrong wrote:
> On 01/12/2018 16:17, Carlo Caione wrote:
> > Kevin is basically doing all the work. Remove my name as co-
> > maintainer.
> 
> Sure, but couldn't we move you as reviewer and add Martin as reviewer
> aswell since he is dedicated to the Meson8X support ?
> 
> Or maybe add a separate entry with Kevin as maintainer and Martin as
> reviewer for Meson8X ?

This. At this point I don't think I will be going to work on the
Meson8X for a while and Martin proved to be the right guy for this job.

So, let's remove my name from here first and then Martin can add a new
entry for Meson8X.

Cheers,

--
Carlo Caione



[PATCH] MAINTAINERS: Remove myself from the list

2018-12-01 Thread Carlo Caione
Kevin is basically doing all the work. Remove my name as co-maintainer.

Signed-off-by: Carlo Caione 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 01645edc2388..63a2ad093524 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1297,7 +1297,6 @@ F:include/dt-bindings/clock/gxbb*
 F: Documentation/devicetree/bindings/clock/amlogic*
 
 ARM/Amlogic Meson SoC support
-M: Carlo Caione 
 M: Kevin Hilman 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 L: linux-amlo...@lists.infradead.org
-- 
2.19.1



[PATCH] MAINTAINERS: Remove myself from the list

2018-12-01 Thread Carlo Caione
Kevin is basically doing all the work. Remove my name as co-maintainer.

Signed-off-by: Carlo Caione 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 01645edc2388..63a2ad093524 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1297,7 +1297,6 @@ F:include/dt-bindings/clock/gxbb*
 F: Documentation/devicetree/bindings/clock/amlogic*
 
 ARM/Amlogic Meson SoC support
-M: Carlo Caione 
 M: Kevin Hilman 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 L: linux-amlo...@lists.infradead.org
-- 
2.19.1



Re: [PATCH v2 0/3] power: supply: Fix AXP288 fallback when not needed

2018-02-16 Thread Carlo Caione
On Fri, Feb 16, 2018 at 8:52 AM, Hans de Goede <hdego...@redhat.com> wrote:
> Hi,

>> Well, to be honest, I very much prefer it when changes are made to one
>> driver at a time.
>
>
> I understand completely, Carlo can you do a v4 with the changes
> Rafael requested please? Feel free to keep my Reviewed-by for the v4.

No problem. Thank you both for the reviews.

Cheers,

-- 
Carlo Caione  |  +44.7384.69.16.04  |  Endless


Re: [PATCH v2 0/3] power: supply: Fix AXP288 fallback when not needed

2018-02-16 Thread Carlo Caione
On Fri, Feb 16, 2018 at 8:52 AM, Hans de Goede  wrote:
> Hi,

>> Well, to be honest, I very much prefer it when changes are made to one
>> driver at a time.
>
>
> I understand completely, Carlo can you do a v4 with the changes
> Rafael requested please? Feel free to keep my Reviewed-by for the v4.

No problem. Thank you both for the reviews.

Cheers,

-- 
Carlo Caione  |  +44.7384.69.16.04  |  Endless


[PATCH v2 3/3] power: supply: axp288_fuel_gauge: Do not register FG on ECS EF20EA

2018-02-16 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

The ECS EF20EA laptop ships an AXP288 but it is actually using a
different, separate FG chip for AC and battery monitoring. On this
laptop we need to keep using the regular ACPI driver and disable the
AXP288 FG to avoid reporting two batteries to userspace.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 drivers/power/supply/axp288_fuel_gauge.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/power/supply/axp288_fuel_gauge.c 
b/drivers/power/supply/axp288_fuel_gauge.c
index 4cc6e038dfdd..903891a9bcf0 100644
--- a/drivers/power/supply/axp288_fuel_gauge.c
+++ b/drivers/power/supply/axp288_fuel_gauge.c
@@ -708,6 +708,12 @@ static const struct dmi_system_id 
axp288_fuel_gauge_blacklist[] = {
DMI_MATCH(DMI_BOARD_VERSION, "V1.1"),
},
},
+   {
+   /* ECS EF20EA */
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{}
 };
 
-- 
2.14.1



[PATCH v2 3/3] power: supply: axp288_fuel_gauge: Do not register FG on ECS EF20EA

2018-02-16 Thread Carlo Caione
From: Carlo Caione 

The ECS EF20EA laptop ships an AXP288 but it is actually using a
different, separate FG chip for AC and battery monitoring. On this
laptop we need to keep using the regular ACPI driver and disable the
AXP288 FG to avoid reporting two batteries to userspace.

Signed-off-by: Carlo Caione 
---
 drivers/power/supply/axp288_fuel_gauge.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/power/supply/axp288_fuel_gauge.c 
b/drivers/power/supply/axp288_fuel_gauge.c
index 4cc6e038dfdd..903891a9bcf0 100644
--- a/drivers/power/supply/axp288_fuel_gauge.c
+++ b/drivers/power/supply/axp288_fuel_gauge.c
@@ -708,6 +708,12 @@ static const struct dmi_system_id 
axp288_fuel_gauge_blacklist[] = {
DMI_MATCH(DMI_BOARD_VERSION, "V1.1"),
},
},
+   {
+   /* ECS EF20EA */
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{}
 };
 
-- 
2.14.1



[PATCH v2 0/3] power: supply: Fix AXP288 fallback when not needed

2018-02-16 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

With commits af3ec837 and dccfae6d a blacklist was introduced to avoid
using the ACPI drivers for AC and battery when a native PMIC driver was
already present. While this is in general a good idea (because of broken
DSDT or proprietary and undocumented ACPI opregions for the ACPI
AC/battery devices) we have come across at least one CherryTrail laptop
(ECS EF20EA) shipping the AXP288 together with a separate FG controller
(a MAX17047) instead of the one embedded in the AXP288.

This is the interesting analisys done by Hans de Goede (thank you):

Looking at the _BIX method of the BATC/PNP0C0A device, we see it referencing
FG10:

Method (_BIX, 0, NotSerialized)  // _BIX: Battery Information Extend
{
If (AVBL == One)
{
BUF2 = FG10 /* \_SB_.PCI0.I2C1.FG10 */

And FG10 is defined as:

Field (DVFG, BufferAcc, NoLock, Preserve)
{
Connection (SMFG),
Offset (0x10),
AccessAs (BufferAcc, AttribBytes (0x02)),
FG10,   8
}

With SMFG being defined as:

Name (SMFG, ResourceTemplate ()
{
I2cSerialBusV2 (0x0036, ControllerInitiated, 0x000186A0,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
})

Looking for I2C1 address 0x0036 we find:

Device (ANFG)
{
Name (_HID, "MAX17047" /* Fuel Gauge Controller */)  // _HID: Hardwa
Name (_CID, "MAX17047" /* Fuel Gauge Controller */)  // _CID: Compat
Name (_DDN, "Fuel Gauge Controller")  // _DDN: DOS Device Name
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x0001
}
})

Where as the AXP288 PMIC is I2C7 address 0x034:

Device (PMI1)
{
Name (_ADR, Zero)  // _ADR: Address
Name (_HID, "INT33F4" /* XPOWER PMIC Controller */)  // _HID: Ha
Name (_CID, "INT33F4" /* XPOWER PMIC Controller */)  // _CID: Co
Name (_DDN, "XPOWER PMIC Controller")  // _DDN: DOS Device Name
Name (_HRV, 0x03)  // _HRV: Hardware Revision
Name (_UID, One)  // _UID: Unique ID

Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Setti
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0034, ControllerInitiated, 0x000F4240,
AddressingMode7Bit, "\\_SB.PCI0.I2C7",
0x00, ResourceConsumer, , Exclusive,
)

So basically this laptopt is using a separate FG chip instead of the one
embedded in the AXP288.

To have this correctly working we need basically to avoid the fallback on the
AXP288 driver enabling again the ACPI AC/battery drivers and at the same time
avoiding that the AXP288 FG driver is probed at all.

I'm still not fully convinced that having two different quirks (one to disable
the blacklist and another to disable the AXP288 FG probing) is the right way to
fix this. So any comment is welcome.

Changelog:

v2:
  - Split [PATCH 2/2] in two parts
  - Rework subject prefixes

Carlo Caione (3):
  ACPI: AC/battery: Add quirk to avoid using PMIC
  ACPI: AC/battery: Add quirks for ECS EF20EA
  power: supply: axp288_fuel_gauge: Do not register FG on ECS EF20EA

 drivers/acpi/ac.c| 33 
 drivers/acpi/battery.c   | 33 
 drivers/power/supply/axp288_fuel_gauge.c |  6 ++
 3 files changed, 56 insertions(+), 16 deletions(-)

-- 
2.14.1



[PATCH v2 0/3] power: supply: Fix AXP288 fallback when not needed

2018-02-16 Thread Carlo Caione
From: Carlo Caione 

With commits af3ec837 and dccfae6d a blacklist was introduced to avoid
using the ACPI drivers for AC and battery when a native PMIC driver was
already present. While this is in general a good idea (because of broken
DSDT or proprietary and undocumented ACPI opregions for the ACPI
AC/battery devices) we have come across at least one CherryTrail laptop
(ECS EF20EA) shipping the AXP288 together with a separate FG controller
(a MAX17047) instead of the one embedded in the AXP288.

This is the interesting analisys done by Hans de Goede (thank you):

Looking at the _BIX method of the BATC/PNP0C0A device, we see it referencing
FG10:

Method (_BIX, 0, NotSerialized)  // _BIX: Battery Information Extend
{
If (AVBL == One)
{
BUF2 = FG10 /* \_SB_.PCI0.I2C1.FG10 */

And FG10 is defined as:

Field (DVFG, BufferAcc, NoLock, Preserve)
{
Connection (SMFG),
Offset (0x10),
AccessAs (BufferAcc, AttribBytes (0x02)),
FG10,   8
}

With SMFG being defined as:

Name (SMFG, ResourceTemplate ()
{
I2cSerialBusV2 (0x0036, ControllerInitiated, 0x000186A0,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
})

Looking for I2C1 address 0x0036 we find:

Device (ANFG)
{
Name (_HID, "MAX17047" /* Fuel Gauge Controller */)  // _HID: Hardwa
Name (_CID, "MAX17047" /* Fuel Gauge Controller */)  // _CID: Compat
Name (_DDN, "Fuel Gauge Controller")  // _DDN: DOS Device Name
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x0001
}
})

Where as the AXP288 PMIC is I2C7 address 0x034:

Device (PMI1)
{
Name (_ADR, Zero)  // _ADR: Address
Name (_HID, "INT33F4" /* XPOWER PMIC Controller */)  // _HID: Ha
Name (_CID, "INT33F4" /* XPOWER PMIC Controller */)  // _CID: Co
Name (_DDN, "XPOWER PMIC Controller")  // _DDN: DOS Device Name
Name (_HRV, 0x03)  // _HRV: Hardware Revision
Name (_UID, One)  // _UID: Unique ID

Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Setti
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0034, ControllerInitiated, 0x000F4240,
AddressingMode7Bit, "\\_SB.PCI0.I2C7",
0x00, ResourceConsumer, , Exclusive,
)

So basically this laptopt is using a separate FG chip instead of the one
embedded in the AXP288.

To have this correctly working we need basically to avoid the fallback on the
AXP288 driver enabling again the ACPI AC/battery drivers and at the same time
avoiding that the AXP288 FG driver is probed at all.

I'm still not fully convinced that having two different quirks (one to disable
the blacklist and another to disable the AXP288 FG probing) is the right way to
fix this. So any comment is welcome.

Changelog:

v2:
  - Split [PATCH 2/2] in two parts
  - Rework subject prefixes

Carlo Caione (3):
  ACPI: AC/battery: Add quirk to avoid using PMIC
  ACPI: AC/battery: Add quirks for ECS EF20EA
  power: supply: axp288_fuel_gauge: Do not register FG on ECS EF20EA

 drivers/acpi/ac.c| 33 
 drivers/acpi/battery.c   | 33 
 drivers/power/supply/axp288_fuel_gauge.c |  6 ++
 3 files changed, 56 insertions(+), 16 deletions(-)

-- 
2.14.1



[PATCH v2 1/3] ACPI: AC/battery: Add quirk to avoid using PMIC

2018-02-16 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

With commits af3ec837 and dccfae6d a blacklist was introduced to avoid
using the ACPI drivers for AC and battery when a native PMIC driver was
already present. While this is in general a good idea (because of broken
DSDT or proprietary and undocumented ACPI opregions for the ACPI
AC/battery devices) we have come across at least one CherryTrail laptop
(ECS EF20EA) shipping the AXP288 together with a separate FG controller
(a MAX17047) instead of the one embedded in the AXP288.

The net effect of blacklisting the ACPI drivers is that on this platform
the AC/battery reporting is broken since the information is coming from
the AXP288 FG driver, not actually used in hardware.

In this case we want to keep using the ACPI AC/battery driver that is
able to interface correctly with the real FG controller.

We introduce therefore a new quirk to avoid the blacklist.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 drivers/acpi/ac.c  | 26 ++
 drivers/acpi/battery.c | 26 ++
 2 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index 47a7ed557bd6..b9a4ca720309 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -87,6 +87,7 @@ static int acpi_ac_open_fs(struct inode *inode, struct file 
*file);
 
 
 static int ac_sleep_before_get_state_ms;
+static bool ac_not_use_pmic;
 
 static struct acpi_driver acpi_ac_driver = {
.name = "ac",
@@ -316,6 +317,12 @@ static int thinkpad_e530_quirk(const struct dmi_system_id 
*d)
return 0;
 }
 
+static int ac_not_use_pmic_quirk(const struct dmi_system_id *d)
+{
+   ac_not_use_pmic = true;
+   return 0;
+}
+
 static const struct dmi_system_id ac_dmi_table[] = {
{
.callback = thinkpad_e530_quirk,
@@ -384,7 +391,6 @@ static int acpi_ac_add(struct acpi_device *device)
kfree(ac);
}
 
-   dmi_check_system(ac_dmi_table);
return result;
 }
 
@@ -442,13 +448,17 @@ static int __init acpi_ac_init(void)
if (acpi_disabled)
return -ENODEV;
 
-   for (i = 0; i < ARRAY_SIZE(acpi_ac_blacklist); i++)
-   if (acpi_dev_present(acpi_ac_blacklist[i].hid, "1",
-acpi_ac_blacklist[i].hrv)) {
-   pr_info(PREFIX "AC: found native %s PMIC, not 
loading\n",
-   acpi_ac_blacklist[i].hid);
-   return -ENODEV;
-   }
+   dmi_check_system(ac_dmi_table);
+
+   if (!ac_not_use_pmic) {
+   for (i = 0; i < ARRAY_SIZE(acpi_ac_blacklist); i++)
+   if (acpi_dev_present(acpi_ac_blacklist[i].hid, "1",
+acpi_ac_blacklist[i].hrv)) {
+   pr_info(PREFIX "AC: found native %s PMIC, not 
loading\n",
+   acpi_ac_blacklist[i].hid);
+   return -ENODEV;
+   }
+   }
 
 #ifdef CONFIG_ACPI_PROCFS_POWER
acpi_ac_dir = acpi_lock_ac_dir();
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 7128488a3a72..258d2e66f230 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -71,6 +71,7 @@ static bool battery_driver_registered;
 static int battery_bix_broken_package;
 static int battery_notification_delay_ms;
 static int battery_full_discharging;
+static bool battery_not_use_pmic;
 static unsigned int cache_time = 1000;
 module_param(cache_time, uint, 0644);
 MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
@@ -1176,6 +1177,13 @@ static int __init battery_full_discharging_quirk(const 
struct dmi_system_id *d)
return 0;
 }
 
+static int __init
+battery_not_use_pmic_quirk(const struct dmi_system_id *d)
+{
+   battery_not_use_pmic = true;
+   return 0;
+}
+
 static const struct dmi_system_id bat_dmi_table[] __initconst = {
{
.callback = battery_bix_broken_package_quirk,
@@ -1364,16 +1372,18 @@ static void __init acpi_battery_init_async(void 
*unused, async_cookie_t cookie)
unsigned int i;
int result;
 
-   for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
-   if (acpi_dev_present(acpi_battery_blacklist[i], "1", -1)) {
-   pr_info(PREFIX ACPI_BATTERY_DEVICE_NAME
-   ": found native %s PMIC, not loading\n",
-   acpi_battery_blacklist[i]);
-   return;
-   }
-
dmi_check_system(bat_dmi_table);
 
+   if (!battery_not_use_pmic) {
+   for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
+   if (acpi_dev_present(acpi_battery_blacklist[i], "1", 
-1)) {
+   pr_i

[PATCH v2 1/3] ACPI: AC/battery: Add quirk to avoid using PMIC

2018-02-16 Thread Carlo Caione
From: Carlo Caione 

With commits af3ec837 and dccfae6d a blacklist was introduced to avoid
using the ACPI drivers for AC and battery when a native PMIC driver was
already present. While this is in general a good idea (because of broken
DSDT or proprietary and undocumented ACPI opregions for the ACPI
AC/battery devices) we have come across at least one CherryTrail laptop
(ECS EF20EA) shipping the AXP288 together with a separate FG controller
(a MAX17047) instead of the one embedded in the AXP288.

The net effect of blacklisting the ACPI drivers is that on this platform
the AC/battery reporting is broken since the information is coming from
the AXP288 FG driver, not actually used in hardware.

In this case we want to keep using the ACPI AC/battery driver that is
able to interface correctly with the real FG controller.

We introduce therefore a new quirk to avoid the blacklist.

Signed-off-by: Carlo Caione 
---
 drivers/acpi/ac.c  | 26 ++
 drivers/acpi/battery.c | 26 ++
 2 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index 47a7ed557bd6..b9a4ca720309 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -87,6 +87,7 @@ static int acpi_ac_open_fs(struct inode *inode, struct file 
*file);
 
 
 static int ac_sleep_before_get_state_ms;
+static bool ac_not_use_pmic;
 
 static struct acpi_driver acpi_ac_driver = {
.name = "ac",
@@ -316,6 +317,12 @@ static int thinkpad_e530_quirk(const struct dmi_system_id 
*d)
return 0;
 }
 
+static int ac_not_use_pmic_quirk(const struct dmi_system_id *d)
+{
+   ac_not_use_pmic = true;
+   return 0;
+}
+
 static const struct dmi_system_id ac_dmi_table[] = {
{
.callback = thinkpad_e530_quirk,
@@ -384,7 +391,6 @@ static int acpi_ac_add(struct acpi_device *device)
kfree(ac);
}
 
-   dmi_check_system(ac_dmi_table);
return result;
 }
 
@@ -442,13 +448,17 @@ static int __init acpi_ac_init(void)
if (acpi_disabled)
return -ENODEV;
 
-   for (i = 0; i < ARRAY_SIZE(acpi_ac_blacklist); i++)
-   if (acpi_dev_present(acpi_ac_blacklist[i].hid, "1",
-acpi_ac_blacklist[i].hrv)) {
-   pr_info(PREFIX "AC: found native %s PMIC, not 
loading\n",
-   acpi_ac_blacklist[i].hid);
-   return -ENODEV;
-   }
+   dmi_check_system(ac_dmi_table);
+
+   if (!ac_not_use_pmic) {
+   for (i = 0; i < ARRAY_SIZE(acpi_ac_blacklist); i++)
+   if (acpi_dev_present(acpi_ac_blacklist[i].hid, "1",
+acpi_ac_blacklist[i].hrv)) {
+   pr_info(PREFIX "AC: found native %s PMIC, not 
loading\n",
+   acpi_ac_blacklist[i].hid);
+   return -ENODEV;
+   }
+   }
 
 #ifdef CONFIG_ACPI_PROCFS_POWER
acpi_ac_dir = acpi_lock_ac_dir();
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 7128488a3a72..258d2e66f230 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -71,6 +71,7 @@ static bool battery_driver_registered;
 static int battery_bix_broken_package;
 static int battery_notification_delay_ms;
 static int battery_full_discharging;
+static bool battery_not_use_pmic;
 static unsigned int cache_time = 1000;
 module_param(cache_time, uint, 0644);
 MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
@@ -1176,6 +1177,13 @@ static int __init battery_full_discharging_quirk(const 
struct dmi_system_id *d)
return 0;
 }
 
+static int __init
+battery_not_use_pmic_quirk(const struct dmi_system_id *d)
+{
+   battery_not_use_pmic = true;
+   return 0;
+}
+
 static const struct dmi_system_id bat_dmi_table[] __initconst = {
{
.callback = battery_bix_broken_package_quirk,
@@ -1364,16 +1372,18 @@ static void __init acpi_battery_init_async(void 
*unused, async_cookie_t cookie)
unsigned int i;
int result;
 
-   for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
-   if (acpi_dev_present(acpi_battery_blacklist[i], "1", -1)) {
-   pr_info(PREFIX ACPI_BATTERY_DEVICE_NAME
-   ": found native %s PMIC, not loading\n",
-   acpi_battery_blacklist[i]);
-   return;
-   }
-
dmi_check_system(bat_dmi_table);
 
+   if (!battery_not_use_pmic) {
+   for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
+   if (acpi_dev_present(acpi_battery_blacklist[i], "1", 
-1)) {
+   pr_info(PREFIX A

[PATCH v2 2/3] ACPI: AC/battery: Add quirks for ECS EF20EA

2018-02-16 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

On the ECS EF20EA laptop we need to move away from the AXP288 FG driver
and enable again the ACPI AC/battery drivers. Add the required quirks to
do that. We rely only on the product name because all the other DMI
entries are dummy or not filled in on this platform.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 drivers/acpi/ac.c  | 7 +++
 drivers/acpi/battery.c | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index b9a4ca720309..39f778f954f5 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -332,6 +332,13 @@ static const struct dmi_system_id ac_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "32597CG"),
},
},
+   {
+   .callback = ac_not_use_pmic_quirk,
+   .ident = "ECS EF20EA",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{},
 };
 
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 258d2e66f230..fe024f1a8ad5 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -1233,6 +1233,13 @@ static const struct dmi_system_id bat_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "UX410UAK"),
},
},
+   {
+   .callback = battery_not_use_pmic_quirk,
+   .ident = "ECS EF20EA",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{},
 };
 
-- 
2.14.1



[PATCH v2 2/3] ACPI: AC/battery: Add quirks for ECS EF20EA

2018-02-16 Thread Carlo Caione
From: Carlo Caione 

On the ECS EF20EA laptop we need to move away from the AXP288 FG driver
and enable again the ACPI AC/battery drivers. Add the required quirks to
do that. We rely only on the product name because all the other DMI
entries are dummy or not filled in on this platform.

Signed-off-by: Carlo Caione 
---
 drivers/acpi/ac.c  | 7 +++
 drivers/acpi/battery.c | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index b9a4ca720309..39f778f954f5 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -332,6 +332,13 @@ static const struct dmi_system_id ac_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "32597CG"),
},
},
+   {
+   .callback = ac_not_use_pmic_quirk,
+   .ident = "ECS EF20EA",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{},
 };
 
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 258d2e66f230..fe024f1a8ad5 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -1233,6 +1233,13 @@ static const struct dmi_system_id bat_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "UX410UAK"),
},
},
+   {
+   .callback = battery_not_use_pmic_quirk,
+   .ident = "ECS EF20EA",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{},
 };
 
-- 
2.14.1



Re: [PATCH v2] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO

2018-02-15 Thread Carlo Caione
On Fri, Feb 9, 2018 at 2:23 PM, Carlo Caione <ca...@caione.org> wrote:
> From: Carlo Caione <ca...@endlessm.com>
>
> On at least one notebook (ECS EF20EA) the 'hp-detect' GPIO is defined in
> the DSDT table by the ACPI GpioIo resources in _CRS. Add this mapping to
> the rt5645 driver to enable the jack detection also on non-DT platforms.

Please do not merge this yet, I'll submit a V3 soon.
Hans pointed out that on some BayTrail there is indeed an extra GPIO
but it is used to enable the external speaker amplifier. Better to
guard this by a quirk.

Cheers,

-- 
Carlo Caione


Re: [PATCH v2] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO

2018-02-15 Thread Carlo Caione
On Fri, Feb 9, 2018 at 2:23 PM, Carlo Caione  wrote:
> From: Carlo Caione 
>
> On at least one notebook (ECS EF20EA) the 'hp-detect' GPIO is defined in
> the DSDT table by the ACPI GpioIo resources in _CRS. Add this mapping to
> the rt5645 driver to enable the jack detection also on non-DT platforms.

Please do not merge this yet, I'll submit a V3 soon.
Hans pointed out that on some BayTrail there is indeed an extra GPIO
but it is used to enable the external speaker amplifier. Better to
guard this by a quirk.

Cheers,

-- 
Carlo Caione


[PATCH 0/2] power: supply: Fix AXP288 fallback when not needed

2018-02-14 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

With commits af3ec837 and dccfae6d a blacklist was introduced to avoid
using the ACPI drivers for AC and battery when a native PMIC driver was
already present. While this is in general a good idea (because of broken
DSDT or proprietary and undocumented ACPI opregions for the ACPI
AC/battery devices) we have come across at least one CherryTrail laptop
(ECS EF20EA) shipping the AXP288 together with a separate FG controller
(a MAX17047) instead of the one embedded in the AXP288.

This is the interesting analisys done by Hans de Goede (thank you):

Looking at the _BIX method of the BATC/PNP0C0A device, we see it referencing
FG10:

Method (_BIX, 0, NotSerialized)  // _BIX: Battery Information Extend
{
If (AVBL == One)
{
BUF2 = FG10 /* \_SB_.PCI0.I2C1.FG10 */

And FG10 is defined as:

Field (DVFG, BufferAcc, NoLock, Preserve)
{
Connection (SMFG),
Offset (0x10),
AccessAs (BufferAcc, AttribBytes (0x02)),
FG10,   8
}

With SMFG being defined as:

Name (SMFG, ResourceTemplate ()
{
I2cSerialBusV2 (0x0036, ControllerInitiated, 0x000186A0,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
})

Looking for I2C1 address 0x0036 we find:

Device (ANFG)
{
Name (_HID, "MAX17047" /* Fuel Gauge Controller */)  // _HID: Hardwa
Name (_CID, "MAX17047" /* Fuel Gauge Controller */)  // _CID: Compat
Name (_DDN, "Fuel Gauge Controller")  // _DDN: DOS Device Name
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x0001
}
})

Where as the AXP288 PMIC is I2C7 address 0x034:

Device (PMI1)
{
Name (_ADR, Zero)  // _ADR: Address
Name (_HID, "INT33F4" /* XPOWER PMIC Controller */)  // _HID: Ha
Name (_CID, "INT33F4" /* XPOWER PMIC Controller */)  // _CID: Co
Name (_DDN, "XPOWER PMIC Controller")  // _DDN: DOS Device Name
Name (_HRV, 0x03)  // _HRV: Hardware Revision
Name (_UID, One)  // _UID: Unique ID

Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Setti
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0034, ControllerInitiated, 0x000F4240,
AddressingMode7Bit, "\\_SB.PCI0.I2C7",
0x00, ResourceConsumer, , Exclusive,
)

So basically this laptopt is using a separate FG chip instead of the one
embedded in the AXP288.

To have this correctly working we need basically to avoid the fallback on the
AXP288 driver enabling again the ACPI AC/battery drivers and at the same time
avoiding that the AXP288 FG driver is probed at all.

I'm still not fully convinced that having two different quirks (one to disable
the blacklist and another to disable the AXP288 FG probing) is the right way to
fix this. So any comment is welcome.

Carlo Caione (2):
  power: supply: ACPI/AXP288: Add quirk to avoid using PMIC
  power: supply: ACPI/AXP288: Add quirks for ECS EF20EA

 drivers/acpi/ac.c| 33 
 drivers/acpi/battery.c   | 33 
 drivers/power/supply/axp288_fuel_gauge.c |  6 ++
 3 files changed, 56 insertions(+), 16 deletions(-)

-- 
2.14.1



[PATCH 0/2] power: supply: Fix AXP288 fallback when not needed

2018-02-14 Thread Carlo Caione
From: Carlo Caione 

With commits af3ec837 and dccfae6d a blacklist was introduced to avoid
using the ACPI drivers for AC and battery when a native PMIC driver was
already present. While this is in general a good idea (because of broken
DSDT or proprietary and undocumented ACPI opregions for the ACPI
AC/battery devices) we have come across at least one CherryTrail laptop
(ECS EF20EA) shipping the AXP288 together with a separate FG controller
(a MAX17047) instead of the one embedded in the AXP288.

This is the interesting analisys done by Hans de Goede (thank you):

Looking at the _BIX method of the BATC/PNP0C0A device, we see it referencing
FG10:

Method (_BIX, 0, NotSerialized)  // _BIX: Battery Information Extend
{
If (AVBL == One)
{
BUF2 = FG10 /* \_SB_.PCI0.I2C1.FG10 */

And FG10 is defined as:

Field (DVFG, BufferAcc, NoLock, Preserve)
{
Connection (SMFG),
Offset (0x10),
AccessAs (BufferAcc, AttribBytes (0x02)),
FG10,   8
}

With SMFG being defined as:

Name (SMFG, ResourceTemplate ()
{
I2cSerialBusV2 (0x0036, ControllerInitiated, 0x000186A0,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
})

Looking for I2C1 address 0x0036 we find:

Device (ANFG)
{
Name (_HID, "MAX17047" /* Fuel Gauge Controller */)  // _HID: Hardwa
Name (_CID, "MAX17047" /* Fuel Gauge Controller */)  // _CID: Compat
Name (_DDN, "Fuel Gauge Controller")  // _DDN: DOS Device Name
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C1",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x0001
}
})

Where as the AXP288 PMIC is I2C7 address 0x034:

Device (PMI1)
{
Name (_ADR, Zero)  // _ADR: Address
Name (_HID, "INT33F4" /* XPOWER PMIC Controller */)  // _HID: Ha
Name (_CID, "INT33F4" /* XPOWER PMIC Controller */)  // _CID: Co
Name (_DDN, "XPOWER PMIC Controller")  // _DDN: DOS Device Name
Name (_HRV, 0x03)  // _HRV: Hardware Revision
Name (_UID, One)  // _UID: Unique ID

Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Setti
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0034, ControllerInitiated, 0x000F4240,
AddressingMode7Bit, "\\_SB.PCI0.I2C7",
0x00, ResourceConsumer, , Exclusive,
)

So basically this laptopt is using a separate FG chip instead of the one
embedded in the AXP288.

To have this correctly working we need basically to avoid the fallback on the
AXP288 driver enabling again the ACPI AC/battery drivers and at the same time
avoiding that the AXP288 FG driver is probed at all.

I'm still not fully convinced that having two different quirks (one to disable
the blacklist and another to disable the AXP288 FG probing) is the right way to
fix this. So any comment is welcome.

Carlo Caione (2):
  power: supply: ACPI/AXP288: Add quirk to avoid using PMIC
  power: supply: ACPI/AXP288: Add quirks for ECS EF20EA

 drivers/acpi/ac.c| 33 
 drivers/acpi/battery.c   | 33 
 drivers/power/supply/axp288_fuel_gauge.c |  6 ++
 3 files changed, 56 insertions(+), 16 deletions(-)

-- 
2.14.1



[PATCH 2/2] power: supply: ACPI/AXP288: Add quirks for ECS EF20EA

2018-02-14 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

On the ECS EF20EA laptop we need to move away from the AXP288 FG driver
and enable again the ACPI AC/battery drivers. Add the required quirks to
do that. We rely only on the product name because all the other DMI
entries are dummy or not filled in on this platform.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 drivers/acpi/ac.c| 7 +++
 drivers/acpi/battery.c   | 7 +++
 drivers/power/supply/axp288_fuel_gauge.c | 6 ++
 3 files changed, 20 insertions(+)

diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index b9a4ca720309..39f778f954f5 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -332,6 +332,13 @@ static const struct dmi_system_id ac_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "32597CG"),
},
},
+   {
+   .callback = ac_not_use_pmic_quirk,
+   .ident = "ECS EF20EA",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{},
 };
 
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 258d2e66f230..fe024f1a8ad5 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -1233,6 +1233,13 @@ static const struct dmi_system_id bat_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "UX410UAK"),
},
},
+   {
+   .callback = battery_not_use_pmic_quirk,
+   .ident = "ECS EF20EA",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{},
 };
 
diff --git a/drivers/power/supply/axp288_fuel_gauge.c 
b/drivers/power/supply/axp288_fuel_gauge.c
index 4cc6e038dfdd..903891a9bcf0 100644
--- a/drivers/power/supply/axp288_fuel_gauge.c
+++ b/drivers/power/supply/axp288_fuel_gauge.c
@@ -708,6 +708,12 @@ static const struct dmi_system_id 
axp288_fuel_gauge_blacklist[] = {
DMI_MATCH(DMI_BOARD_VERSION, "V1.1"),
},
},
+   {
+   /* ECS EF20EA */
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{}
 };
 
-- 
2.14.1



[PATCH 2/2] power: supply: ACPI/AXP288: Add quirks for ECS EF20EA

2018-02-14 Thread Carlo Caione
From: Carlo Caione 

On the ECS EF20EA laptop we need to move away from the AXP288 FG driver
and enable again the ACPI AC/battery drivers. Add the required quirks to
do that. We rely only on the product name because all the other DMI
entries are dummy or not filled in on this platform.

Signed-off-by: Carlo Caione 
---
 drivers/acpi/ac.c| 7 +++
 drivers/acpi/battery.c   | 7 +++
 drivers/power/supply/axp288_fuel_gauge.c | 6 ++
 3 files changed, 20 insertions(+)

diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index b9a4ca720309..39f778f954f5 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -332,6 +332,13 @@ static const struct dmi_system_id ac_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "32597CG"),
},
},
+   {
+   .callback = ac_not_use_pmic_quirk,
+   .ident = "ECS EF20EA",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{},
 };
 
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 258d2e66f230..fe024f1a8ad5 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -1233,6 +1233,13 @@ static const struct dmi_system_id bat_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "UX410UAK"),
},
},
+   {
+   .callback = battery_not_use_pmic_quirk,
+   .ident = "ECS EF20EA",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{},
 };
 
diff --git a/drivers/power/supply/axp288_fuel_gauge.c 
b/drivers/power/supply/axp288_fuel_gauge.c
index 4cc6e038dfdd..903891a9bcf0 100644
--- a/drivers/power/supply/axp288_fuel_gauge.c
+++ b/drivers/power/supply/axp288_fuel_gauge.c
@@ -708,6 +708,12 @@ static const struct dmi_system_id 
axp288_fuel_gauge_blacklist[] = {
DMI_MATCH(DMI_BOARD_VERSION, "V1.1"),
},
},
+   {
+   /* ECS EF20EA */
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{}
 };
 
-- 
2.14.1



[PATCH 1/2] power: supply: ACPI/AXP288: Add quirk to avoid using PMIC

2018-02-14 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

With commits af3ec837 and dccfae6d a blacklist was introduced to avoid
using the ACPI drivers for AC and battery when a native PMIC driver was
already present. While this is in general a good idea (because of broken
DSDT or proprietary and undocumented ACPI opregions for the ACPI
AC/battery devices) we have come across at least one CherryTrail laptop
(ECS EF20EA) shipping the AXP288 together with a separate FG controller
(a MAX17047) instead of the one embedded in the AXP288.

The net effect of blacklisting the ACPI drivers is that on this platform
the AC/battery reporting is broken since the information is coming from
the AXP288 FG driver, not actually used in hardware.

In this case we want to keep using the ACPI AC/battery driver that is
able to interface correctly with the real FG controller.

We introduce therefore a new quirk to avoid the blacklist.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 drivers/acpi/ac.c  | 26 ++
 drivers/acpi/battery.c | 26 ++
 2 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index 47a7ed557bd6..b9a4ca720309 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -87,6 +87,7 @@ static int acpi_ac_open_fs(struct inode *inode, struct file 
*file);
 
 
 static int ac_sleep_before_get_state_ms;
+static bool ac_not_use_pmic;
 
 static struct acpi_driver acpi_ac_driver = {
.name = "ac",
@@ -316,6 +317,12 @@ static int thinkpad_e530_quirk(const struct dmi_system_id 
*d)
return 0;
 }
 
+static int ac_not_use_pmic_quirk(const struct dmi_system_id *d)
+{
+   ac_not_use_pmic = true;
+   return 0;
+}
+
 static const struct dmi_system_id ac_dmi_table[] = {
{
.callback = thinkpad_e530_quirk,
@@ -384,7 +391,6 @@ static int acpi_ac_add(struct acpi_device *device)
kfree(ac);
}
 
-   dmi_check_system(ac_dmi_table);
return result;
 }
 
@@ -442,13 +448,17 @@ static int __init acpi_ac_init(void)
if (acpi_disabled)
return -ENODEV;
 
-   for (i = 0; i < ARRAY_SIZE(acpi_ac_blacklist); i++)
-   if (acpi_dev_present(acpi_ac_blacklist[i].hid, "1",
-acpi_ac_blacklist[i].hrv)) {
-   pr_info(PREFIX "AC: found native %s PMIC, not 
loading\n",
-   acpi_ac_blacklist[i].hid);
-   return -ENODEV;
-   }
+   dmi_check_system(ac_dmi_table);
+
+   if (!ac_not_use_pmic) {
+   for (i = 0; i < ARRAY_SIZE(acpi_ac_blacklist); i++)
+   if (acpi_dev_present(acpi_ac_blacklist[i].hid, "1",
+acpi_ac_blacklist[i].hrv)) {
+   pr_info(PREFIX "AC: found native %s PMIC, not 
loading\n",
+   acpi_ac_blacklist[i].hid);
+   return -ENODEV;
+   }
+   }
 
 #ifdef CONFIG_ACPI_PROCFS_POWER
acpi_ac_dir = acpi_lock_ac_dir();
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 7128488a3a72..258d2e66f230 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -71,6 +71,7 @@ static bool battery_driver_registered;
 static int battery_bix_broken_package;
 static int battery_notification_delay_ms;
 static int battery_full_discharging;
+static bool battery_not_use_pmic;
 static unsigned int cache_time = 1000;
 module_param(cache_time, uint, 0644);
 MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
@@ -1176,6 +1177,13 @@ static int __init battery_full_discharging_quirk(const 
struct dmi_system_id *d)
return 0;
 }
 
+static int __init
+battery_not_use_pmic_quirk(const struct dmi_system_id *d)
+{
+   battery_not_use_pmic = true;
+   return 0;
+}
+
 static const struct dmi_system_id bat_dmi_table[] __initconst = {
{
.callback = battery_bix_broken_package_quirk,
@@ -1364,16 +1372,18 @@ static void __init acpi_battery_init_async(void 
*unused, async_cookie_t cookie)
unsigned int i;
int result;
 
-   for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
-   if (acpi_dev_present(acpi_battery_blacklist[i], "1", -1)) {
-   pr_info(PREFIX ACPI_BATTERY_DEVICE_NAME
-   ": found native %s PMIC, not loading\n",
-   acpi_battery_blacklist[i]);
-   return;
-   }
-
dmi_check_system(bat_dmi_table);
 
+   if (!battery_not_use_pmic) {
+   for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
+   if (acpi_dev_present(acpi_battery_blacklist[i], "1", 
-1)) {
+   pr_i

[PATCH 1/2] power: supply: ACPI/AXP288: Add quirk to avoid using PMIC

2018-02-14 Thread Carlo Caione
From: Carlo Caione 

With commits af3ec837 and dccfae6d a blacklist was introduced to avoid
using the ACPI drivers for AC and battery when a native PMIC driver was
already present. While this is in general a good idea (because of broken
DSDT or proprietary and undocumented ACPI opregions for the ACPI
AC/battery devices) we have come across at least one CherryTrail laptop
(ECS EF20EA) shipping the AXP288 together with a separate FG controller
(a MAX17047) instead of the one embedded in the AXP288.

The net effect of blacklisting the ACPI drivers is that on this platform
the AC/battery reporting is broken since the information is coming from
the AXP288 FG driver, not actually used in hardware.

In this case we want to keep using the ACPI AC/battery driver that is
able to interface correctly with the real FG controller.

We introduce therefore a new quirk to avoid the blacklist.

Signed-off-by: Carlo Caione 
---
 drivers/acpi/ac.c  | 26 ++
 drivers/acpi/battery.c | 26 ++
 2 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index 47a7ed557bd6..b9a4ca720309 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -87,6 +87,7 @@ static int acpi_ac_open_fs(struct inode *inode, struct file 
*file);
 
 
 static int ac_sleep_before_get_state_ms;
+static bool ac_not_use_pmic;
 
 static struct acpi_driver acpi_ac_driver = {
.name = "ac",
@@ -316,6 +317,12 @@ static int thinkpad_e530_quirk(const struct dmi_system_id 
*d)
return 0;
 }
 
+static int ac_not_use_pmic_quirk(const struct dmi_system_id *d)
+{
+   ac_not_use_pmic = true;
+   return 0;
+}
+
 static const struct dmi_system_id ac_dmi_table[] = {
{
.callback = thinkpad_e530_quirk,
@@ -384,7 +391,6 @@ static int acpi_ac_add(struct acpi_device *device)
kfree(ac);
}
 
-   dmi_check_system(ac_dmi_table);
return result;
 }
 
@@ -442,13 +448,17 @@ static int __init acpi_ac_init(void)
if (acpi_disabled)
return -ENODEV;
 
-   for (i = 0; i < ARRAY_SIZE(acpi_ac_blacklist); i++)
-   if (acpi_dev_present(acpi_ac_blacklist[i].hid, "1",
-acpi_ac_blacklist[i].hrv)) {
-   pr_info(PREFIX "AC: found native %s PMIC, not 
loading\n",
-   acpi_ac_blacklist[i].hid);
-   return -ENODEV;
-   }
+   dmi_check_system(ac_dmi_table);
+
+   if (!ac_not_use_pmic) {
+   for (i = 0; i < ARRAY_SIZE(acpi_ac_blacklist); i++)
+   if (acpi_dev_present(acpi_ac_blacklist[i].hid, "1",
+acpi_ac_blacklist[i].hrv)) {
+   pr_info(PREFIX "AC: found native %s PMIC, not 
loading\n",
+   acpi_ac_blacklist[i].hid);
+   return -ENODEV;
+   }
+   }
 
 #ifdef CONFIG_ACPI_PROCFS_POWER
acpi_ac_dir = acpi_lock_ac_dir();
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 7128488a3a72..258d2e66f230 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -71,6 +71,7 @@ static bool battery_driver_registered;
 static int battery_bix_broken_package;
 static int battery_notification_delay_ms;
 static int battery_full_discharging;
+static bool battery_not_use_pmic;
 static unsigned int cache_time = 1000;
 module_param(cache_time, uint, 0644);
 MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
@@ -1176,6 +1177,13 @@ static int __init battery_full_discharging_quirk(const 
struct dmi_system_id *d)
return 0;
 }
 
+static int __init
+battery_not_use_pmic_quirk(const struct dmi_system_id *d)
+{
+   battery_not_use_pmic = true;
+   return 0;
+}
+
 static const struct dmi_system_id bat_dmi_table[] __initconst = {
{
.callback = battery_bix_broken_package_quirk,
@@ -1364,16 +1372,18 @@ static void __init acpi_battery_init_async(void 
*unused, async_cookie_t cookie)
unsigned int i;
int result;
 
-   for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
-   if (acpi_dev_present(acpi_battery_blacklist[i], "1", -1)) {
-   pr_info(PREFIX ACPI_BATTERY_DEVICE_NAME
-   ": found native %s PMIC, not loading\n",
-   acpi_battery_blacklist[i]);
-   return;
-   }
-
dmi_check_system(bat_dmi_table);
 
+   if (!battery_not_use_pmic) {
+   for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
+   if (acpi_dev_present(acpi_battery_blacklist[i], "1", 
-1)) {
+   pr_info(PREFIX A

[PATCH v2] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO

2018-02-09 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

On at least one notebook (ECS EF20EA) the 'hp-detect' GPIO is defined in
the DSDT table by the ACPI GpioIo resources in _CRS. Add this mapping to
the rt5645 driver to enable the jack detection also on non-DT platforms.

Method (_CRS, 0, NotSerialized)
{
  Name (SBUF, ResourceTemplate ()
  {
I2cSerialBusV2 (0x001A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C2",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
GpioIo (Shared, PullDefault, 0x, 0x, IoRestrictionInputOnly,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
  })
  Return (SBUF) /* \_SB_.PCI0.I2C2.RTK2._CRS.SBUF */
}

Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
Signed-off-by: Carlo Caione <ca...@endlessm.com>
---

Changelog:

v2:
  - s/ACPI_HANDLE/has_acpi_companion/
---
 sound/soc/codecs/rt5645.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 8f140c8b93ac..8e3d1e4ddb63 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3764,6 +3764,13 @@ static int rt5645_parse_dt(struct rt5645_priv *rt5645, 
struct device *dev)
return 0;
 }
 
+static const struct acpi_gpio_params hp_detect_gpios = { 1, 0, false };
+
+static const struct acpi_gpio_mapping cht_rt5645_gpios[] = {
+   { "hp-detect-gpios", _detect_gpios, 1 },
+   {},
+};
+
 static int rt5645_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
 {
@@ -3779,6 +3786,10 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
if (rt5645 == NULL)
return -ENOMEM;
 
+   if (has_acpi_companion(>dev))
+   if (devm_acpi_dev_add_driver_gpios(>dev, cht_rt5645_gpios))
+   dev_dbg(>dev, "Failed to add driver gpios\n");
+
rt5645->i2c = i2c;
i2c_set_clientdata(i2c, rt5645);
 
-- 
2.14.1



[PATCH v2] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO

2018-02-09 Thread Carlo Caione
From: Carlo Caione 

On at least one notebook (ECS EF20EA) the 'hp-detect' GPIO is defined in
the DSDT table by the ACPI GpioIo resources in _CRS. Add this mapping to
the rt5645 driver to enable the jack detection also on non-DT platforms.

Method (_CRS, 0, NotSerialized)
{
  Name (SBUF, ResourceTemplate ()
  {
I2cSerialBusV2 (0x001A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C2",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
GpioIo (Shared, PullDefault, 0x, 0x, IoRestrictionInputOnly,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
  })
  Return (SBUF) /* \_SB_.PCI0.I2C2.RTK2._CRS.SBUF */
}

Reviewed-by: Andy Shevchenko 
Signed-off-by: Carlo Caione 
---

Changelog:

v2:
  - s/ACPI_HANDLE/has_acpi_companion/
---
 sound/soc/codecs/rt5645.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 8f140c8b93ac..8e3d1e4ddb63 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3764,6 +3764,13 @@ static int rt5645_parse_dt(struct rt5645_priv *rt5645, 
struct device *dev)
return 0;
 }
 
+static const struct acpi_gpio_params hp_detect_gpios = { 1, 0, false };
+
+static const struct acpi_gpio_mapping cht_rt5645_gpios[] = {
+   { "hp-detect-gpios", _detect_gpios, 1 },
+   {},
+};
+
 static int rt5645_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
 {
@@ -3779,6 +3786,10 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
if (rt5645 == NULL)
return -ENOMEM;
 
+   if (has_acpi_companion(>dev))
+   if (devm_acpi_dev_add_driver_gpios(>dev, cht_rt5645_gpios))
+   dev_dbg(>dev, "Failed to add driver gpios\n");
+
rt5645->i2c = i2c;
i2c_set_clientdata(i2c, rt5645);
 
-- 
2.14.1



[PATCH] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO

2018-02-08 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

On at least one notebook (ECS EF20EA) the 'hp-detect' GPIO is defined in
the DSDT table by the ACPI GpioIo resources in _CRS. Add this mapping to
the rt5645 driver to enable the jack detection also on non-DT platforms.

Method (_CRS, 0, NotSerialized)
{
  Name (SBUF, ResourceTemplate ()
  {
I2cSerialBusV2 (0x001A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C2",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
GpioIo (Shared, PullDefault, 0x, 0x, IoRestrictionInputOnly,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
  })
  Return (SBUF) /* \_SB_.PCI0.I2C2.RTK2._CRS.SBUF */
}

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/codecs/rt5645.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 8f140c8b93ac..7f2d83884556 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3764,6 +3764,13 @@ static int rt5645_parse_dt(struct rt5645_priv *rt5645, 
struct device *dev)
return 0;
 }
 
+static const struct acpi_gpio_params hp_detect_gpios = { 1, 0, false };
+
+static const struct acpi_gpio_mapping cht_rt5645_gpios[] = {
+   { "hp-detect-gpios", _detect_gpios, 1 },
+   {},
+};
+
 static int rt5645_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
 {
@@ -3779,6 +3786,10 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
if (rt5645 == NULL)
return -ENOMEM;
 
+   if (ACPI_HANDLE(>dev))
+   if (devm_acpi_dev_add_driver_gpios(>dev, cht_rt5645_gpios))
+   dev_dbg(>dev, "Failed to add driver gpios\n");
+
rt5645->i2c = i2c;
i2c_set_clientdata(i2c, rt5645);
 
-- 
2.14.1



[PATCH] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO

2018-02-08 Thread Carlo Caione
From: Carlo Caione 

On at least one notebook (ECS EF20EA) the 'hp-detect' GPIO is defined in
the DSDT table by the ACPI GpioIo resources in _CRS. Add this mapping to
the rt5645 driver to enable the jack detection also on non-DT platforms.

Method (_CRS, 0, NotSerialized)
{
  Name (SBUF, ResourceTemplate ()
  {
I2cSerialBusV2 (0x001A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C2",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
GpioIo (Shared, PullDefault, 0x, 0x, IoRestrictionInputOnly,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
  })
  Return (SBUF) /* \_SB_.PCI0.I2C2.RTK2._CRS.SBUF */
}

Signed-off-by: Carlo Caione 
---
 sound/soc/codecs/rt5645.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 8f140c8b93ac..7f2d83884556 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3764,6 +3764,13 @@ static int rt5645_parse_dt(struct rt5645_priv *rt5645, 
struct device *dev)
return 0;
 }
 
+static const struct acpi_gpio_params hp_detect_gpios = { 1, 0, false };
+
+static const struct acpi_gpio_mapping cht_rt5645_gpios[] = {
+   { "hp-detect-gpios", _detect_gpios, 1 },
+   {},
+};
+
 static int rt5645_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
 {
@@ -3779,6 +3786,10 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
if (rt5645 == NULL)
return -ENOMEM;
 
+   if (ACPI_HANDLE(>dev))
+   if (devm_acpi_dev_add_driver_gpios(>dev, cht_rt5645_gpios))
+   dev_dbg(>dev, "Failed to add driver gpios\n");
+
rt5645->i2c = i2c;
i2c_set_clientdata(i2c, rt5645);
 
-- 
2.14.1



Re: [PATCH] ACPI / LPSS: Add device link for CHT SD card dependency on I2C

2017-12-04 Thread Carlo Caione
On Mon, Dec 4, 2017 at 12:32 PM, Adrian Hunter <adrian.hun...@intel.com> wrote:
> Some Cherry Trail boards have a dependency between the SDHCI host
> controller used for SD cards and an external PMIC accessed via I2C. Add a
> device link between the SDHCI host controller (consumer) and the I2C
> adapter (supplier).
>
> This patch depends on a fix to devices links, namely commit 0ff26c662d5f
> ("driver core: Fix device link deferred probe"). And also either,
> commit 126dbc6b49c8 ("PM: i2c-designware-platdrv: Clean up PM handling in
> probe"), or patch "PM / runtime: Fix handling of suppliers with disabled
> runtime PM".
>
> Signed-off-by: Adrian Hunter <adrian.hun...@intel.com>

Hey Adrian,
thank you for working on this.

I tried this patch on top of linus HEAD (0ff26c662d5f and 126dbc6b49c8
are already applied) but I'm still experiencing some difficulties with
some SD cards on the cherry-trail laptop I'm working with. You can
find the DSDT in [0].

With an ultra high speed SDR104 SDHC card I get:

  mmc2: Tuning timeout, falling back to fixed sampling clock
  mmc2: new ultra high speed SDR104 SDHC card at address 59b4
  mmcblk2: mmc2:59b4 USD00 15.0 GiB
  mmc2: Timeout waiting for hardware interrupt.
  mmc2: sdhci:  SDHCI REGISTER DUMP ===
  mmc2: sdhci: Sys addr:  0x0008 | Version:  0x1002
  mmc2: sdhci: Blk size:  0x7200 | Blk cnt:  0x0008
  mmc2: sdhci: Argument:  0x | Trn mode: 0x003b
  mmc2: sdhci: Present:   0x01ff0001 | Host ctl: 0x0017
  mmc2: sdhci: Power: 0x000f | Blk gap:  0x0080
  mmc2: sdhci: Wake-up:   0x | Clock:0x0007
  mmc2: sdhci: Timeout:   0x000a | Int stat: 0x
  mmc2: sdhci: Int enab:  0x02ff008b | Sig enab: 0x02ff008b
  mmc2: sdhci: AC12 err:  0x | Slot int: 0x
  mmc2: sdhci: Caps:  0x0568c8b2 | Caps_1:   0x0807
  mmc2: sdhci: Cmd:   0x123a | Max curr: 0x
  mmc2: sdhci: Resp[0]:   0x | Resp[1]:  0x0077dd7f
  mmc2: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x
  mmc2: sdhci: Host ctl2: 0x800b
  mmc2: sdhci: ADMA Err:  0x | ADMA Ptr: 0x33773200
  mmc2: sdhci: 
  mmcblk2: error -110 sending status command, retrying
  mmcblk2: error -110 sending status command, retrying
  mmcblk2: error -110 sending status command, aborting
  mmc2: Tuning timeout, falling back to fixed sampling clock

For an high speed SDHC card I simply get:

  mmc2: error -110 whilst initialising SD card

Some other cards just work fine, i.e. ultra high speed DDR50.

At this point I'm not sure if the problem I'm seeing is actually
related to the issue you are fixing with this commit (and if now,
sorry to have hijacked this thread).
Any idea on that?

Thank you,

[0] https://gist.github.com/carlocaione/82bff95ababb67dd33f52a86e94ce3ff

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


Re: [PATCH] ACPI / LPSS: Add device link for CHT SD card dependency on I2C

2017-12-04 Thread Carlo Caione
On Mon, Dec 4, 2017 at 12:32 PM, Adrian Hunter  wrote:
> Some Cherry Trail boards have a dependency between the SDHCI host
> controller used for SD cards and an external PMIC accessed via I2C. Add a
> device link between the SDHCI host controller (consumer) and the I2C
> adapter (supplier).
>
> This patch depends on a fix to devices links, namely commit 0ff26c662d5f
> ("driver core: Fix device link deferred probe"). And also either,
> commit 126dbc6b49c8 ("PM: i2c-designware-platdrv: Clean up PM handling in
> probe"), or patch "PM / runtime: Fix handling of suppliers with disabled
> runtime PM".
>
> Signed-off-by: Adrian Hunter 

Hey Adrian,
thank you for working on this.

I tried this patch on top of linus HEAD (0ff26c662d5f and 126dbc6b49c8
are already applied) but I'm still experiencing some difficulties with
some SD cards on the cherry-trail laptop I'm working with. You can
find the DSDT in [0].

With an ultra high speed SDR104 SDHC card I get:

  mmc2: Tuning timeout, falling back to fixed sampling clock
  mmc2: new ultra high speed SDR104 SDHC card at address 59b4
  mmcblk2: mmc2:59b4 USD00 15.0 GiB
  mmc2: Timeout waiting for hardware interrupt.
  mmc2: sdhci:  SDHCI REGISTER DUMP ===
  mmc2: sdhci: Sys addr:  0x0008 | Version:  0x1002
  mmc2: sdhci: Blk size:  0x7200 | Blk cnt:  0x0008
  mmc2: sdhci: Argument:  0x | Trn mode: 0x003b
  mmc2: sdhci: Present:   0x01ff0001 | Host ctl: 0x0017
  mmc2: sdhci: Power: 0x000f | Blk gap:  0x0080
  mmc2: sdhci: Wake-up:   0x | Clock:0x0007
  mmc2: sdhci: Timeout:   0x000a | Int stat: 0x
  mmc2: sdhci: Int enab:  0x02ff008b | Sig enab: 0x02ff008b
  mmc2: sdhci: AC12 err:  0x | Slot int: 0x
  mmc2: sdhci: Caps:  0x0568c8b2 | Caps_1:   0x0807
  mmc2: sdhci: Cmd:   0x123a | Max curr: 0x
  mmc2: sdhci: Resp[0]:   0x | Resp[1]:  0x0077dd7f
  mmc2: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x
  mmc2: sdhci: Host ctl2: 0x800b
  mmc2: sdhci: ADMA Err:  0x | ADMA Ptr: 0x33773200
  mmc2: sdhci: 
  mmcblk2: error -110 sending status command, retrying
  mmcblk2: error -110 sending status command, retrying
  mmcblk2: error -110 sending status command, aborting
  mmc2: Tuning timeout, falling back to fixed sampling clock

For an high speed SDHC card I simply get:

  mmc2: error -110 whilst initialising SD card

Some other cards just work fine, i.e. ultra high speed DDR50.

At this point I'm not sure if the problem I'm seeing is actually
related to the issue you are fixing with this commit (and if now,
sorry to have hijacked this thread).
Any idea on that?

Thank you,

[0] https://gist.github.com/carlocaione/82bff95ababb67dd33f52a86e94ce3ff

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


Re: [PATCH 0/2] Update codec driver for dual mics configuration

2017-11-28 Thread Carlo Caione
On Tue, Nov 21, 2017 at 5:15 PM, Carlo Caione <ca...@caione.org> wrote:
> From: Carlo Caione <ca...@endlessm.com>
>
> The RT5651 codec has 3 analog input ports. Some laptops (like the KIANO 
> laptop)
> have two different analog mics on two ports, leaving the headset on the
> remaining one. We need to add a new quirk to support also this configuration.
>
> Carlo Caione (2):
>   ASoC: intel: byt: Introduce new map for dual mics
>   ASoC: intel: byt: Fix quirk for KIANO laptop

gentle ping.

cheers,

-- 
Carlo Caione


Re: [PATCH 0/2] Update codec driver for dual mics configuration

2017-11-28 Thread Carlo Caione
On Tue, Nov 21, 2017 at 5:15 PM, Carlo Caione  wrote:
> From: Carlo Caione 
>
> The RT5651 codec has 3 analog input ports. Some laptops (like the KIANO 
> laptop)
> have two different analog mics on two ports, leaving the headset on the
> remaining one. We need to add a new quirk to support also this configuration.
>
> Carlo Caione (2):
>   ASoC: intel: byt: Introduce new map for dual mics
>   ASoC: intel: byt: Fix quirk for KIANO laptop

gentle ping.

cheers,

-- 
Carlo Caione


[PATCH 1/2] ASoC: intel: byt: Introduce new map for dual mics

2017-11-21 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

The RT5651 codec has 3 analog inputs. Some laptops have two different
internal analog microphones on the external case.
Add a new custom quirk mapping the two internal mics on IN1P / IN2P,
leaving the headset mic on IN3P.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/intel/boards/bytcr_rt5651.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index d955836c6870..e3d5e6ea707f 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -38,6 +38,7 @@ enum {
BYT_RT5651_DMIC_MAP,
BYT_RT5651_IN1_MAP,
BYT_RT5651_IN2_MAP,
+   BYT_RT5651_IN1_IN2_MAP,
 };
 
 #define BYT_RT5651_MAP(quirk)  ((quirk) & GENMASK(7, 0))
@@ -171,6 +172,13 @@ static const struct snd_soc_dapm_route 
byt_rt5651_intmic_in2_map[] = {
{"IN2P", NULL, "Internal Mic"},
 };
 
+static const struct snd_soc_dapm_route byt_rt5651_intmic_in1_in2_map[] = {
+   {"Internal Mic", NULL, "micbias1"},
+   {"IN1P", NULL, "Internal Mic"},
+   {"IN2P", NULL, "Internal Mic"},
+   {"IN3P", NULL, "Headset Mic"},
+};
+
 static const struct snd_kcontrol_new byt_rt5651_controls[] = {
SOC_DAPM_PIN_SWITCH("Headphone"),
SOC_DAPM_PIN_SWITCH("Headset Mic"),
@@ -281,6 +289,10 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
custom_map = byt_rt5651_intmic_in2_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_in2_map);
break;
+   case BYT_RT5651_IN1_IN2_MAP:
+   custom_map = byt_rt5651_intmic_in1_in2_map;
+   num_routes = ARRAY_SIZE(byt_rt5651_intmic_in1_in2_map);
+   break;
default:
custom_map = byt_rt5651_intmic_dmic_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_dmic_map);
-- 
2.14.1



[PATCH 1/2] ASoC: intel: byt: Introduce new map for dual mics

2017-11-21 Thread Carlo Caione
From: Carlo Caione 

The RT5651 codec has 3 analog inputs. Some laptops have two different
internal analog microphones on the external case.
Add a new custom quirk mapping the two internal mics on IN1P / IN2P,
leaving the headset mic on IN3P.

Signed-off-by: Carlo Caione 
---
 sound/soc/intel/boards/bytcr_rt5651.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index d955836c6870..e3d5e6ea707f 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -38,6 +38,7 @@ enum {
BYT_RT5651_DMIC_MAP,
BYT_RT5651_IN1_MAP,
BYT_RT5651_IN2_MAP,
+   BYT_RT5651_IN1_IN2_MAP,
 };
 
 #define BYT_RT5651_MAP(quirk)  ((quirk) & GENMASK(7, 0))
@@ -171,6 +172,13 @@ static const struct snd_soc_dapm_route 
byt_rt5651_intmic_in2_map[] = {
{"IN2P", NULL, "Internal Mic"},
 };
 
+static const struct snd_soc_dapm_route byt_rt5651_intmic_in1_in2_map[] = {
+   {"Internal Mic", NULL, "micbias1"},
+   {"IN1P", NULL, "Internal Mic"},
+   {"IN2P", NULL, "Internal Mic"},
+   {"IN3P", NULL, "Headset Mic"},
+};
+
 static const struct snd_kcontrol_new byt_rt5651_controls[] = {
SOC_DAPM_PIN_SWITCH("Headphone"),
SOC_DAPM_PIN_SWITCH("Headset Mic"),
@@ -281,6 +289,10 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
custom_map = byt_rt5651_intmic_in2_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_in2_map);
break;
+   case BYT_RT5651_IN1_IN2_MAP:
+   custom_map = byt_rt5651_intmic_in1_in2_map;
+   num_routes = ARRAY_SIZE(byt_rt5651_intmic_in1_in2_map);
+   break;
default:
custom_map = byt_rt5651_intmic_dmic_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_dmic_map);
-- 
2.14.1



[PATCH 0/2] Update codec driver for dual mics configuration

2017-11-21 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

The RT5651 codec has 3 analog input ports. Some laptops (like the KIANO laptop)
have two different analog mics on two ports, leaving the headset on the
remaining one. We need to add a new quirk to support also this configuration.

Carlo Caione (2):
  ASoC: intel: byt: Introduce new map for dual mics
  ASoC: intel: byt: Fix quirk for KIANO laptop

 sound/soc/intel/boards/bytcr_rt5651.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

-- 
2.14.1



[PATCH 0/2] Update codec driver for dual mics configuration

2017-11-21 Thread Carlo Caione
From: Carlo Caione 

The RT5651 codec has 3 analog input ports. Some laptops (like the KIANO laptop)
have two different analog mics on two ports, leaving the headset on the
remaining one. We need to add a new quirk to support also this configuration.

Carlo Caione (2):
  ASoC: intel: byt: Introduce new map for dual mics
  ASoC: intel: byt: Fix quirk for KIANO laptop

 sound/soc/intel/boards/bytcr_rt5651.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

-- 
2.14.1



[PATCH 2/2] ASoC: intel: byt: Fix quirk for KIANO laptop

2017-11-21 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

This laptop has actually two different analog mics, no just one. Fix the
quirk to reflect the correct configuration.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/intel/boards/bytcr_rt5651.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index e3d5e6ea707f..488ec48f296a 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -264,7 +264,7 @@ static const struct dmi_system_id byt_rt5651_quirk_table[] 
= {
DMI_MATCH(DMI_SYS_VENDOR, "KIANO"),
DMI_MATCH(DMI_PRODUCT_NAME, "KIANO SlimNote 14.2"),
},
-   .driver_data = (void *)(BYT_RT5651_IN2_MAP),
+   .driver_data = (void *)(BYT_RT5651_IN1_IN2_MAP),
},
{}
 };
-- 
2.14.1



[PATCH 2/2] ASoC: intel: byt: Fix quirk for KIANO laptop

2017-11-21 Thread Carlo Caione
From: Carlo Caione 

This laptop has actually two different analog mics, no just one. Fix the
quirk to reflect the correct configuration.

Signed-off-by: Carlo Caione 
---
 sound/soc/intel/boards/bytcr_rt5651.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index e3d5e6ea707f..488ec48f296a 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -264,7 +264,7 @@ static const struct dmi_system_id byt_rt5651_quirk_table[] 
= {
DMI_MATCH(DMI_SYS_VENDOR, "KIANO"),
DMI_MATCH(DMI_PRODUCT_NAME, "KIANO SlimNote 14.2"),
},
-   .driver_data = (void *)(BYT_RT5651_IN2_MAP),
+   .driver_data = (void *)(BYT_RT5651_IN1_IN2_MAP),
},
{}
 };
-- 
2.14.1



Re: [alsa-devel] [PATCH] SoC: intel: byt: Introduce new custom IN2 map

2017-11-21 Thread Carlo Caione
On Thu, Nov 16, 2017 at 1:53 PM, Carlo Caione <ca...@caione.org> wrote:
> On Wed, Oct 18, 2017 at 7:05 PM, Pierre-Louis Bossart
> <pierre-louis.boss...@linux.intel.com> wrote:
>> On 10/18/17 11:49 AM, Carlo Caione wrote:
>>>
>>> From: Carlo Caione <ca...@endlessm.com>
>>>
>>> Introduce a new custom dapm routes map to quirk platforms with the
>>> internal mic connected to IN2P.
>>
>>
>> LGTM. If we start getting more quirks for this codec, we should think of
>> adding a module parameters to select them from the command line or with
>> modprobe (as done in other machine drivers).
>
> Hey Pierre,
> I'm currently working on a laptop (always with the rt5651 codec)
> having two separate internal mics (on IN1P and IN2P) and the headset
> on IN3P. I was thinking how to describe this situation in the current
> driver without having to add all the 6 different configuration as
> quirks. Any suggestion?

gentle ping on this question.

cheers,

-- 
Carlo Caione


Re: [alsa-devel] [PATCH] SoC: intel: byt: Introduce new custom IN2 map

2017-11-21 Thread Carlo Caione
On Thu, Nov 16, 2017 at 1:53 PM, Carlo Caione  wrote:
> On Wed, Oct 18, 2017 at 7:05 PM, Pierre-Louis Bossart
>  wrote:
>> On 10/18/17 11:49 AM, Carlo Caione wrote:
>>>
>>> From: Carlo Caione 
>>>
>>> Introduce a new custom dapm routes map to quirk platforms with the
>>> internal mic connected to IN2P.
>>
>>
>> LGTM. If we start getting more quirks for this codec, we should think of
>> adding a module parameters to select them from the command line or with
>> modprobe (as done in other machine drivers).
>
> Hey Pierre,
> I'm currently working on a laptop (always with the rt5651 codec)
> having two separate internal mics (on IN1P and IN2P) and the headset
> on IN3P. I was thinking how to describe this situation in the current
> driver without having to add all the 6 different configuration as
> quirks. Any suggestion?

gentle ping on this question.

cheers,

-- 
Carlo Caione


Re: [alsa-devel] [PATCH] SoC: intel: byt: Introduce new custom IN2 map

2017-11-16 Thread Carlo Caione
On Wed, Oct 18, 2017 at 7:05 PM, Pierre-Louis Bossart
<pierre-louis.boss...@linux.intel.com> wrote:
> On 10/18/17 11:49 AM, Carlo Caione wrote:
>>
>> From: Carlo Caione <ca...@endlessm.com>
>>
>> Introduce a new custom dapm routes map to quirk platforms with the
>> internal mic connected to IN2P.
>
>
> LGTM. If we start getting more quirks for this codec, we should think of
> adding a module parameters to select them from the command line or with
> modprobe (as done in other machine drivers).

Hey Pierre,
I'm currently working on a laptop (always with the rt5651 codec)
having two separate internal mics (on IN1P and IN2P) and the headset
on IN3P. I was thinking how to describe this situation in the current
driver without having to add all the 6 different configuration as
quirks. Any suggestion?

Cheers,

-- 
Carlo Caione


Re: [alsa-devel] [PATCH] SoC: intel: byt: Introduce new custom IN2 map

2017-11-16 Thread Carlo Caione
On Wed, Oct 18, 2017 at 7:05 PM, Pierre-Louis Bossart
 wrote:
> On 10/18/17 11:49 AM, Carlo Caione wrote:
>>
>> From: Carlo Caione 
>>
>> Introduce a new custom dapm routes map to quirk platforms with the
>> internal mic connected to IN2P.
>
>
> LGTM. If we start getting more quirks for this codec, we should think of
> adding a module parameters to select them from the command line or with
> modprobe (as done in other machine drivers).

Hey Pierre,
I'm currently working on a laptop (always with the rt5651 codec)
having two separate internal mics (on IN1P and IN2P) and the headset
on IN3P. I was thinking how to describe this situation in the current
driver without having to add all the 6 different configuration as
quirks. Any suggestion?

Cheers,

-- 
Carlo Caione


Re: [PATCH] ASoC: rt5651: Convert rt5651 micbias1 to a supply widget

2017-10-21 Thread Carlo Caione
On Sat, Oct 21, 2017 at 11:09 AM, Mark Brown <broo...@kernel.org> wrote:
> On Wed, Oct 18, 2017 at 06:06:31PM +0100, Carlo Caione wrote:
>> From: Carlo Caione <ca...@endlessm.com>
>>
>> MICBIAS widget type has been deprecated. Convert it to a SUPPLY widget.
>
> Do we have any machine drivers using this?  If it was just a simple
> substitution then we'd have just done the conversion but the routing for
> MICBIAS was funky, requiring that it be looped into the path.

We have bytcr_rt5651.c already using it as a supply (source) widget.
Also this change is required to have the jack detection working fine
using the set of patches posted in [0]

thanks,

[0] https://www.spinics.net/lists/kernel/msg2630096.html

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


Re: [PATCH] ASoC: rt5651: Convert rt5651 micbias1 to a supply widget

2017-10-21 Thread Carlo Caione
On Sat, Oct 21, 2017 at 11:09 AM, Mark Brown  wrote:
> On Wed, Oct 18, 2017 at 06:06:31PM +0100, Carlo Caione wrote:
>> From: Carlo Caione 
>>
>> MICBIAS widget type has been deprecated. Convert it to a SUPPLY widget.
>
> Do we have any machine drivers using this?  If it was just a simple
> substitution then we'd have just done the conversion but the routing for
> MICBIAS was funky, requiring that it be looped into the path.

We have bytcr_rt5651.c already using it as a supply (source) widget.
Also this change is required to have the jack detection working fine
using the set of patches posted in [0]

thanks,

[0] https://www.spinics.net/lists/kernel/msg2630096.html

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


[PATCH v2 3/5] ASoC: intel: byt: Enable IN2 map quirk for a KIANO laptop

2017-10-20 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

This cherry-trails laptop has the internal mic connected to the IN2
input pins. Enable the quirk to correctly map the routes.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/intel/boards/bytcr_rt5651.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 5aca55baccda..c7494f88ab81 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -250,6 +250,14 @@ static const struct dmi_system_id byt_rt5651_quirk_table[] 
= {
.driver_data = (void *)(BYT_RT5651_DMIC_MAP |
BYT_RT5651_DMIC_EN),
},
+   {
+   .callback = byt_rt5651_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "KIANO"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "KIANO SlimNote 14.2"),
+   },
+   .driver_data = (void *)(BYT_RT5651_IN2_MAP),
+   },
{}
 };
 
-- 
2.14.2



[PATCH v2 2/5] ASoC: intel: byt: Add headset jack

2017-10-20 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Introduce an headset jack in the machine driver and register it to the
codec driver.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/intel/boards/bytcr_rt5651.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 1dad5c98c9ef..5aca55baccda 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -47,6 +47,7 @@ enum {
 
 struct byt_rt5651_private {
struct clk *mclk;
+   struct snd_soc_jack jack;
 };
 
 static unsigned long byt_rt5651_quirk = BYT_RT5651_DMIC_MAP |
@@ -177,6 +178,17 @@ static const struct snd_kcontrol_new byt_rt5651_controls[] 
= {
SOC_DAPM_PIN_SWITCH("Speaker"),
 };
 
+static struct snd_soc_jack_pin bytcr_jack_pins[] = {
+   {
+   .pin= "Headphone",
+   .mask   = SND_JACK_HEADPHONE,
+   },
+   {
+   .pin= "Headset Mic",
+   .mask   = SND_JACK_MICROPHONE,
+   },
+};
+
 static int byt_rt5651_aif1_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
 {
@@ -244,6 +256,7 @@ static const struct dmi_system_id byt_rt5651_quirk_table[] 
= {
 static int byt_rt5651_init(struct snd_soc_pcm_runtime *runtime)
 {
struct snd_soc_card *card = runtime->card;
+   struct snd_soc_codec *codec = runtime->codec;
struct byt_rt5651_private *priv = snd_soc_card_get_drvdata(card);
const struct snd_soc_dapm_route *custom_map;
int num_routes;
@@ -301,6 +314,16 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
dev_err(card->dev, "unable to set MCLK rate\n");
}
 
+   ret = snd_soc_card_jack_new(runtime->card, "Headset",
+   SND_JACK_HEADSET, >jack,
+   bytcr_jack_pins, 
ARRAY_SIZE(bytcr_jack_pins));
+   if (ret) {
+   dev_err(runtime->dev, "Headset jack creation failed %d\n", ret);
+   return ret;
+   }
+
+   rt5651_set_jack_detect(codec, >jack);
+
return ret;
 }
 
-- 
2.14.2



[PATCH v2 3/5] ASoC: intel: byt: Enable IN2 map quirk for a KIANO laptop

2017-10-20 Thread Carlo Caione
From: Carlo Caione 

This cherry-trails laptop has the internal mic connected to the IN2
input pins. Enable the quirk to correctly map the routes.

Signed-off-by: Carlo Caione 
---
 sound/soc/intel/boards/bytcr_rt5651.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 5aca55baccda..c7494f88ab81 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -250,6 +250,14 @@ static const struct dmi_system_id byt_rt5651_quirk_table[] 
= {
.driver_data = (void *)(BYT_RT5651_DMIC_MAP |
BYT_RT5651_DMIC_EN),
},
+   {
+   .callback = byt_rt5651_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "KIANO"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "KIANO SlimNote 14.2"),
+   },
+   .driver_data = (void *)(BYT_RT5651_IN2_MAP),
+   },
{}
 };
 
-- 
2.14.2



[PATCH v2 2/5] ASoC: intel: byt: Add headset jack

2017-10-20 Thread Carlo Caione
From: Carlo Caione 

Introduce an headset jack in the machine driver and register it to the
codec driver.

Signed-off-by: Carlo Caione 
---
 sound/soc/intel/boards/bytcr_rt5651.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 1dad5c98c9ef..5aca55baccda 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -47,6 +47,7 @@ enum {
 
 struct byt_rt5651_private {
struct clk *mclk;
+   struct snd_soc_jack jack;
 };
 
 static unsigned long byt_rt5651_quirk = BYT_RT5651_DMIC_MAP |
@@ -177,6 +178,17 @@ static const struct snd_kcontrol_new byt_rt5651_controls[] 
= {
SOC_DAPM_PIN_SWITCH("Speaker"),
 };
 
+static struct snd_soc_jack_pin bytcr_jack_pins[] = {
+   {
+   .pin= "Headphone",
+   .mask   = SND_JACK_HEADPHONE,
+   },
+   {
+   .pin= "Headset Mic",
+   .mask   = SND_JACK_MICROPHONE,
+   },
+};
+
 static int byt_rt5651_aif1_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
 {
@@ -244,6 +256,7 @@ static const struct dmi_system_id byt_rt5651_quirk_table[] 
= {
 static int byt_rt5651_init(struct snd_soc_pcm_runtime *runtime)
 {
struct snd_soc_card *card = runtime->card;
+   struct snd_soc_codec *codec = runtime->codec;
struct byt_rt5651_private *priv = snd_soc_card_get_drvdata(card);
const struct snd_soc_dapm_route *custom_map;
int num_routes;
@@ -301,6 +314,16 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
dev_err(card->dev, "unable to set MCLK rate\n");
}
 
+   ret = snd_soc_card_jack_new(runtime->card, "Headset",
+   SND_JACK_HEADSET, >jack,
+   bytcr_jack_pins, 
ARRAY_SIZE(bytcr_jack_pins));
+   if (ret) {
+   dev_err(runtime->dev, "Headset jack creation failed %d\n", ret);
+   return ret;
+   }
+
+   rt5651_set_jack_detect(codec, >jack);
+
return ret;
 }
 
-- 
2.14.2



[PATCH v2 4/5] ASoC: rt5651: Rework quirk logic

2017-10-20 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Rework a bit the quirk logic in the codec driver to simplify the
DMI-based quirk assignment for non-DT platforms.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/codecs/rt5651.c | 39 +++
 1 file changed, 35 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index 91f254391452..f01d41101631 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,10 @@
 #include "rl6231.h"
 #include "rt5651.h"
 
+#define RT5651_JD_MAP(quirk)   ((quirk) & GENMASK(7, 0))
+#define RT5651_IN2_DIFFBIT(16)
+#define RT5651_DMIC_EN BIT(17)
+
 #define RT5651_DEVICE_ID_VALUE 0x6281
 
 #define RT5651_PR_RANGE_BASE (0xff + 1)
@@ -38,6 +43,8 @@
 
 #define RT5651_PR_BASE (RT5651_PR_RANGE_BASE + (0 * RT5651_PR_SPACING))
 
+static unsigned long rt5651_quirk;
+
 static const struct regmap_range_cfg rt5651_ranges[] = {
{ .name = "PR", .range_min = RT5651_PR_BASE,
  .range_max = RT5651_PR_BASE + 0xb4,
@@ -1739,16 +1746,36 @@ static const struct i2c_device_id rt5651_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, rt5651_i2c_id);
 
+static int rt5651_quirk_cb(const struct dmi_system_id *id)
+{
+   rt5651_quirk = (unsigned long) id->driver_data;
+   return 1;
+}
+
+static const struct dmi_system_id rt5651_quirk_table[] = {
+   {}
+};
+
 static int rt5651_parse_dt(struct rt5651_priv *rt5651, struct device_node *np)
 {
-   rt5651->pdata.in2_diff = of_property_read_bool(np,
-   "realtek,in2-differential");
-   rt5651->pdata.dmic_en = of_property_read_bool(np,
-   "realtek,dmic-en");
+   if (of_property_read_bool(np, "realtek,in2-differential"))
+   rt5651_quirk |= RT5651_IN2_DIFF;
+   if (of_property_read_bool(np, "realtek,dmic-en"))
+   rt5651_quirk |= RT5651_DMIC_EN;
 
return 0;
 }
 
+static void rt5651_set_pdata(struct rt5651_priv *rt5651)
+{
+   if (rt5651_quirk & RT5651_IN2_DIFF)
+   rt5651->pdata.in2_diff = true;
+   if (rt5651_quirk & RT5651_DMIC_EN)
+   rt5651->pdata.dmic_en = true;
+   if (RT5651_JD_MAP(rt5651_quirk))
+   rt5651->pdata.jd_src = RT5651_JD_MAP(rt5651_quirk);
+}
+
 static irqreturn_t rt5651_irq(int irq, void *data)
 {
struct rt5651_priv *rt5651 = data;
@@ -1854,6 +1881,10 @@ static int rt5651_i2c_probe(struct i2c_client *i2c,
rt5651->pdata = *pdata;
else if (i2c->dev.of_node)
rt5651_parse_dt(rt5651, i2c->dev.of_node);
+   else
+   dmi_check_system(rt5651_quirk_table);
+
+   rt5651_set_pdata(rt5651);
 
rt5651->regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(rt5651->regmap)) {
-- 
2.14.2



[PATCH v2 4/5] ASoC: rt5651: Rework quirk logic

2017-10-20 Thread Carlo Caione
From: Carlo Caione 

Rework a bit the quirk logic in the codec driver to simplify the
DMI-based quirk assignment for non-DT platforms.

Signed-off-by: Carlo Caione 
---
 sound/soc/codecs/rt5651.c | 39 +++
 1 file changed, 35 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index 91f254391452..f01d41101631 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,10 @@
 #include "rl6231.h"
 #include "rt5651.h"
 
+#define RT5651_JD_MAP(quirk)   ((quirk) & GENMASK(7, 0))
+#define RT5651_IN2_DIFFBIT(16)
+#define RT5651_DMIC_EN BIT(17)
+
 #define RT5651_DEVICE_ID_VALUE 0x6281
 
 #define RT5651_PR_RANGE_BASE (0xff + 1)
@@ -38,6 +43,8 @@
 
 #define RT5651_PR_BASE (RT5651_PR_RANGE_BASE + (0 * RT5651_PR_SPACING))
 
+static unsigned long rt5651_quirk;
+
 static const struct regmap_range_cfg rt5651_ranges[] = {
{ .name = "PR", .range_min = RT5651_PR_BASE,
  .range_max = RT5651_PR_BASE + 0xb4,
@@ -1739,16 +1746,36 @@ static const struct i2c_device_id rt5651_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, rt5651_i2c_id);
 
+static int rt5651_quirk_cb(const struct dmi_system_id *id)
+{
+   rt5651_quirk = (unsigned long) id->driver_data;
+   return 1;
+}
+
+static const struct dmi_system_id rt5651_quirk_table[] = {
+   {}
+};
+
 static int rt5651_parse_dt(struct rt5651_priv *rt5651, struct device_node *np)
 {
-   rt5651->pdata.in2_diff = of_property_read_bool(np,
-   "realtek,in2-differential");
-   rt5651->pdata.dmic_en = of_property_read_bool(np,
-   "realtek,dmic-en");
+   if (of_property_read_bool(np, "realtek,in2-differential"))
+   rt5651_quirk |= RT5651_IN2_DIFF;
+   if (of_property_read_bool(np, "realtek,dmic-en"))
+   rt5651_quirk |= RT5651_DMIC_EN;
 
return 0;
 }
 
+static void rt5651_set_pdata(struct rt5651_priv *rt5651)
+{
+   if (rt5651_quirk & RT5651_IN2_DIFF)
+   rt5651->pdata.in2_diff = true;
+   if (rt5651_quirk & RT5651_DMIC_EN)
+   rt5651->pdata.dmic_en = true;
+   if (RT5651_JD_MAP(rt5651_quirk))
+   rt5651->pdata.jd_src = RT5651_JD_MAP(rt5651_quirk);
+}
+
 static irqreturn_t rt5651_irq(int irq, void *data)
 {
struct rt5651_priv *rt5651 = data;
@@ -1854,6 +1881,10 @@ static int rt5651_i2c_probe(struct i2c_client *i2c,
rt5651->pdata = *pdata;
else if (i2c->dev.of_node)
rt5651_parse_dt(rt5651, i2c->dev.of_node);
+   else
+   dmi_check_system(rt5651_quirk_table);
+
+   rt5651_set_pdata(rt5651);
 
rt5651->regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(rt5651->regmap)) {
-- 
2.14.2



[PATCH v2 5/5] ASoC: rt5651: Enable JD1_1 quirk for KIANO laptopt

2017-10-20 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

The KIANO SlimNote 14.2 laptop uses the JD1_1 input pin for jack
detection. Set the correct quirk in the codec driver.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/codecs/rt5651.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index f01d41101631..831b297978a4 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -1753,6 +1753,14 @@ static int rt5651_quirk_cb(const struct dmi_system_id 
*id)
 }
 
 static const struct dmi_system_id rt5651_quirk_table[] = {
+   {
+   .callback = rt5651_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "KIANO"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "KIANO SlimNote 14.2"),
+   },
+   .driver_data = (unsigned long *) RT5651_JD1_1,
+   },
{}
 };
 
-- 
2.14.2



[PATCH v2 5/5] ASoC: rt5651: Enable JD1_1 quirk for KIANO laptopt

2017-10-20 Thread Carlo Caione
From: Carlo Caione 

The KIANO SlimNote 14.2 laptop uses the JD1_1 input pin for jack
detection. Set the correct quirk in the codec driver.

Signed-off-by: Carlo Caione 
---
 sound/soc/codecs/rt5651.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index f01d41101631..831b297978a4 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -1753,6 +1753,14 @@ static int rt5651_quirk_cb(const struct dmi_system_id 
*id)
 }
 
 static const struct dmi_system_id rt5651_quirk_table[] = {
+   {
+   .callback = rt5651_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "KIANO"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "KIANO SlimNote 14.2"),
+   },
+   .driver_data = (unsigned long *) RT5651_JD1_1,
+   },
{}
 };
 
-- 
2.14.2



[PATCH v2 1/5] ASoC: rt5651: Enable jack detection on JD* pins

2017-10-20 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Enable jack detection for the RT5651 codec on the JD* pins.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 include/sound/rt5651.h|   8 +++
 sound/soc/codecs/rt5651.c | 168 +-
 sound/soc/codecs/rt5651.h |   4 ++
 3 files changed, 178 insertions(+), 2 deletions(-)

diff --git a/include/sound/rt5651.h b/include/sound/rt5651.h
index d35de758dfb5..18b79a761f10 100644
--- a/include/sound/rt5651.h
+++ b/include/sound/rt5651.h
@@ -11,11 +11,19 @@
 #ifndef __LINUX_SND_RT5651_H
 #define __LINUX_SND_RT5651_H
 
+enum rt5651_jd_src {
+   RT5651_JD_NULL,
+   RT5651_JD1_1,
+   RT5651_JD1_2,
+   RT5651_JD2,
+};
+
 struct rt5651_platform_data {
/* IN2 can optionally be differential */
bool in2_diff;
 
bool dmic_en;
+   enum rt5651_jd_src jd_src;
 };
 
 #endif
diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index 28f7210cec91..91f254391452 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rl6231.h"
 #include "rt5651.h"
@@ -880,6 +881,9 @@ static const struct snd_soc_dapm_widget 
rt5651_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("PLL1", RT5651_PWR_ANLG2,
RT5651_PWR_PLL_BIT, 0, NULL, 0),
/* Input Side */
+   SND_SOC_DAPM_SUPPLY("JD Power", RT5651_PWR_ANLG2,
+   RT5651_PWM_JD_M_BIT, 0, NULL, 0),
+
/* micbias */
SND_SOC_DAPM_SUPPLY("LDO", RT5651_PWR_ANLG1,
RT5651_PWR_LDO_BIT, 0, NULL, 0),
@@ -1528,6 +1532,8 @@ static int rt5651_set_dai_pll(struct snd_soc_dai *dai, 
int pll_id, int source,
 static int rt5651_set_bias_level(struct snd_soc_codec *codec,
enum snd_soc_bias_level level)
 {
+   struct rt5651_priv *rt5651 = snd_soc_codec_get_drvdata(codec);
+
switch (level) {
case SND_SOC_BIAS_PREPARE:
if (SND_SOC_BIAS_STANDBY == 
snd_soc_codec_get_bias_level(codec)) {
@@ -1556,8 +1562,13 @@ static int rt5651_set_bias_level(struct snd_soc_codec 
*codec,
snd_soc_write(codec, RT5651_PWR_DIG2, 0x);
snd_soc_write(codec, RT5651_PWR_VOL, 0x);
snd_soc_write(codec, RT5651_PWR_MIXER, 0x);
-   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x);
-   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x);
+   if (rt5651->pdata.jd_src) {
+   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x0204);
+   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x0002);
+   } else {
+   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x);
+   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x);
+   }
break;
 
default:
@@ -1570,6 +1581,7 @@ static int rt5651_set_bias_level(struct snd_soc_codec 
*codec,
 static int rt5651_probe(struct snd_soc_codec *codec)
 {
struct rt5651_priv *rt5651 = snd_soc_codec_get_drvdata(codec);
+   struct snd_soc_dapm_context *dapm = snd_soc_codec_get_dapm(codec);
 
rt5651->codec = codec;
 
@@ -1585,6 +1597,15 @@ static int rt5651_probe(struct snd_soc_codec *codec)
 
snd_soc_codec_force_bias_level(codec, SND_SOC_BIAS_OFF);
 
+   if (rt5651->pdata.jd_src) {
+   snd_soc_dapm_force_enable_pin(dapm, "JD Power");
+   snd_soc_dapm_force_enable_pin(dapm, "LDO");
+   snd_soc_dapm_sync(dapm);
+
+   regmap_update_bits(rt5651->regmap, RT5651_MICBIAS,
+  0x38, 0x38);
+   }
+
return 0;
 }
 
@@ -1728,6 +1749,93 @@ static int rt5651_parse_dt(struct rt5651_priv *rt5651, 
struct device_node *np)
return 0;
 }
 
+static irqreturn_t rt5651_irq(int irq, void *data)
+{
+   struct rt5651_priv *rt5651 = data;
+
+   queue_delayed_work(system_power_efficient_wq,
+  >jack_detect_work, msecs_to_jiffies(250));
+
+   return IRQ_HANDLED;
+}
+
+static int rt5651_jack_detect(struct snd_soc_codec *codec, int jack_insert)
+{
+   struct snd_soc_dapm_context *dapm = snd_soc_codec_get_dapm(codec);
+   int jack_type;
+
+   if (jack_insert) {
+   snd_soc_dapm_force_enable_pin(dapm, "LDO");
+   snd_soc_dapm_sync(dapm);
+
+   snd_soc_update_bits(codec, RT5651_MICBIAS,
+   RT5651_MIC1_OVCD_MASK |
+   RT5651_MIC1_OVTH_MASK |
+   RT5651_PWR_CLK12M_MASK |
+   RT5651_PWR_MB_MASK,
+   RT5651_MIC1_OVCD_EN |
+   RT5651_MIC1_OVTH_600UA |
+

[PATCH v2 0/5] rt5651: Enable jack detection

2017-10-20 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Patchset to support jack detection for the rt5651 codec on the JD* pins
and enable it on the KIANO cherry-trail laptop.

Changelog:
v2:
 - Added quirks for the KIANO laptop
 - Extended support to JD1_2 and JD2 pins
 - Reworked quirk logic in the codec driver
 - Codec driver can now differentiate between headphone and headset
   (thank you Bard Liao)

Carlo Caione (5):
  ASoC: rt5651: Enable jack detection on JD* pins
  ASoC: intel: byt: Add headset jack
  ASoC: intel: byt: Enable IN2 map quirk for a KIANO laptop
  ASoC: rt5651: Rework quirk logic
  ASoC: rt5651: Enable JD1_1 quirk for KIANO laptopt

 include/sound/rt5651.h|   8 ++
 sound/soc/codecs/rt5651.c | 215 +-
 sound/soc/codecs/rt5651.h |   4 +
 sound/soc/intel/boards/bytcr_rt5651.c |  31 +
 4 files changed, 252 insertions(+), 6 deletions(-)

-- 
2.14.2



[PATCH v2 0/5] rt5651: Enable jack detection

2017-10-20 Thread Carlo Caione
From: Carlo Caione 

Patchset to support jack detection for the rt5651 codec on the JD* pins
and enable it on the KIANO cherry-trail laptop.

Changelog:
v2:
 - Added quirks for the KIANO laptop
 - Extended support to JD1_2 and JD2 pins
 - Reworked quirk logic in the codec driver
 - Codec driver can now differentiate between headphone and headset
   (thank you Bard Liao)

Carlo Caione (5):
  ASoC: rt5651: Enable jack detection on JD* pins
  ASoC: intel: byt: Add headset jack
  ASoC: intel: byt: Enable IN2 map quirk for a KIANO laptop
  ASoC: rt5651: Rework quirk logic
  ASoC: rt5651: Enable JD1_1 quirk for KIANO laptopt

 include/sound/rt5651.h|   8 ++
 sound/soc/codecs/rt5651.c | 215 +-
 sound/soc/codecs/rt5651.h |   4 +
 sound/soc/intel/boards/bytcr_rt5651.c |  31 +
 4 files changed, 252 insertions(+), 6 deletions(-)

-- 
2.14.2



[PATCH v2 1/5] ASoC: rt5651: Enable jack detection on JD* pins

2017-10-20 Thread Carlo Caione
From: Carlo Caione 

Enable jack detection for the RT5651 codec on the JD* pins.

Signed-off-by: Carlo Caione 
---
 include/sound/rt5651.h|   8 +++
 sound/soc/codecs/rt5651.c | 168 +-
 sound/soc/codecs/rt5651.h |   4 ++
 3 files changed, 178 insertions(+), 2 deletions(-)

diff --git a/include/sound/rt5651.h b/include/sound/rt5651.h
index d35de758dfb5..18b79a761f10 100644
--- a/include/sound/rt5651.h
+++ b/include/sound/rt5651.h
@@ -11,11 +11,19 @@
 #ifndef __LINUX_SND_RT5651_H
 #define __LINUX_SND_RT5651_H
 
+enum rt5651_jd_src {
+   RT5651_JD_NULL,
+   RT5651_JD1_1,
+   RT5651_JD1_2,
+   RT5651_JD2,
+};
+
 struct rt5651_platform_data {
/* IN2 can optionally be differential */
bool in2_diff;
 
bool dmic_en;
+   enum rt5651_jd_src jd_src;
 };
 
 #endif
diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index 28f7210cec91..91f254391452 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rl6231.h"
 #include "rt5651.h"
@@ -880,6 +881,9 @@ static const struct snd_soc_dapm_widget 
rt5651_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("PLL1", RT5651_PWR_ANLG2,
RT5651_PWR_PLL_BIT, 0, NULL, 0),
/* Input Side */
+   SND_SOC_DAPM_SUPPLY("JD Power", RT5651_PWR_ANLG2,
+   RT5651_PWM_JD_M_BIT, 0, NULL, 0),
+
/* micbias */
SND_SOC_DAPM_SUPPLY("LDO", RT5651_PWR_ANLG1,
RT5651_PWR_LDO_BIT, 0, NULL, 0),
@@ -1528,6 +1532,8 @@ static int rt5651_set_dai_pll(struct snd_soc_dai *dai, 
int pll_id, int source,
 static int rt5651_set_bias_level(struct snd_soc_codec *codec,
enum snd_soc_bias_level level)
 {
+   struct rt5651_priv *rt5651 = snd_soc_codec_get_drvdata(codec);
+
switch (level) {
case SND_SOC_BIAS_PREPARE:
if (SND_SOC_BIAS_STANDBY == 
snd_soc_codec_get_bias_level(codec)) {
@@ -1556,8 +1562,13 @@ static int rt5651_set_bias_level(struct snd_soc_codec 
*codec,
snd_soc_write(codec, RT5651_PWR_DIG2, 0x);
snd_soc_write(codec, RT5651_PWR_VOL, 0x);
snd_soc_write(codec, RT5651_PWR_MIXER, 0x);
-   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x);
-   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x);
+   if (rt5651->pdata.jd_src) {
+   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x0204);
+   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x0002);
+   } else {
+   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x);
+   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x);
+   }
break;
 
default:
@@ -1570,6 +1581,7 @@ static int rt5651_set_bias_level(struct snd_soc_codec 
*codec,
 static int rt5651_probe(struct snd_soc_codec *codec)
 {
struct rt5651_priv *rt5651 = snd_soc_codec_get_drvdata(codec);
+   struct snd_soc_dapm_context *dapm = snd_soc_codec_get_dapm(codec);
 
rt5651->codec = codec;
 
@@ -1585,6 +1597,15 @@ static int rt5651_probe(struct snd_soc_codec *codec)
 
snd_soc_codec_force_bias_level(codec, SND_SOC_BIAS_OFF);
 
+   if (rt5651->pdata.jd_src) {
+   snd_soc_dapm_force_enable_pin(dapm, "JD Power");
+   snd_soc_dapm_force_enable_pin(dapm, "LDO");
+   snd_soc_dapm_sync(dapm);
+
+   regmap_update_bits(rt5651->regmap, RT5651_MICBIAS,
+  0x38, 0x38);
+   }
+
return 0;
 }
 
@@ -1728,6 +1749,93 @@ static int rt5651_parse_dt(struct rt5651_priv *rt5651, 
struct device_node *np)
return 0;
 }
 
+static irqreturn_t rt5651_irq(int irq, void *data)
+{
+   struct rt5651_priv *rt5651 = data;
+
+   queue_delayed_work(system_power_efficient_wq,
+  >jack_detect_work, msecs_to_jiffies(250));
+
+   return IRQ_HANDLED;
+}
+
+static int rt5651_jack_detect(struct snd_soc_codec *codec, int jack_insert)
+{
+   struct snd_soc_dapm_context *dapm = snd_soc_codec_get_dapm(codec);
+   int jack_type;
+
+   if (jack_insert) {
+   snd_soc_dapm_force_enable_pin(dapm, "LDO");
+   snd_soc_dapm_sync(dapm);
+
+   snd_soc_update_bits(codec, RT5651_MICBIAS,
+   RT5651_MIC1_OVCD_MASK |
+   RT5651_MIC1_OVTH_MASK |
+   RT5651_PWR_CLK12M_MASK |
+   RT5651_PWR_MB_MASK,
+   RT5651_MIC1_OVCD_EN |
+   RT5651_MIC1_OVTH_600UA |
+   RT5651_PWR_MB_PU |
+   RT5651_PWR_CL

Re: [alsa-devel] [PATCH 1/2] ASoC: rt5651: Enable jack detection on JD1_1

2017-10-19 Thread Carlo Caione
On Thu, Oct 19, 2017 at 4:47 PM, Pierre-Louis Bossart
<pierre-louis.boss...@linux.intel.com> wrote:
> On 10/19/17 6:03 AM, Carlo Caione wrote:
>>
>> From: Carlo Caione <ca...@endlessm.com>
>>
>> Enable jack detection or the RT5651 codec on the JD1_1 pin.
>
> Nice, but the codec supports a second jack detection on JD1 and has a second
> JD2 pin. I will bet that some devices will have a different routing and I
> wonder if we could just add support for all options.

I can write support for that but I have no hardware to actually test
it, that's why I left those cases out.

>> The codec has no means to detect the type of the jack connected so we
>> assume that the jack is always an headset jack.
>
> that's odd, was this confirmed by Realtek?

The Realtek people are in CC :)
Probably there is way but in the datasheet there is nothing about that
(or did I miss it?)

>> Signed-off-by: Carlo Caione <ca...@endlessm.com>
>> ---
>>   include/sound/rt5651.h|  7 
>>   sound/soc/codecs/rt5651.c | 91
>> +--
>>   sound/soc/codecs/rt5651.h |  3 ++
>>   3 files changed, 99 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/sound/rt5651.h b/include/sound/rt5651.h
>> index d35de758dfb5..c563383149c4 100644
>> --- a/include/sound/rt5651.h
>> +++ b/include/sound/rt5651.h
>> @@ -11,11 +11,18 @@
>>   #ifndef __LINUX_SND_RT5651_H
>>   #define __LINUX_SND_RT5651_H
>>   +enum rt5651_jd_src {
>> +   RT5651_JD_NULL,
>> +   RT5651_JD1_1,
>> +};
>> +
>>   struct rt5651_platform_data {
>> /* IN2 can optionally be differential */
>> bool in2_diff;
>> bool dmic_en;
>> +
>> +   enum rt5651_jd_src jd_src;
>
>
> I don't see code that sets this platform data, is there a quirk or
> of_property missing in this patchset?

Yes, it is supposed to be enabled by a quirk. In general (personal
taste) I prefer to post the quirk enabling code after the base code
has been ACKed. If you feel like it I can post also the quirk code
together with the next respin of this patchset.

Thank you,

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


Re: [alsa-devel] [PATCH 1/2] ASoC: rt5651: Enable jack detection on JD1_1

2017-10-19 Thread Carlo Caione
On Thu, Oct 19, 2017 at 4:47 PM, Pierre-Louis Bossart
 wrote:
> On 10/19/17 6:03 AM, Carlo Caione wrote:
>>
>> From: Carlo Caione 
>>
>> Enable jack detection or the RT5651 codec on the JD1_1 pin.
>
> Nice, but the codec supports a second jack detection on JD1 and has a second
> JD2 pin. I will bet that some devices will have a different routing and I
> wonder if we could just add support for all options.

I can write support for that but I have no hardware to actually test
it, that's why I left those cases out.

>> The codec has no means to detect the type of the jack connected so we
>> assume that the jack is always an headset jack.
>
> that's odd, was this confirmed by Realtek?

The Realtek people are in CC :)
Probably there is way but in the datasheet there is nothing about that
(or did I miss it?)

>> Signed-off-by: Carlo Caione 
>> ---
>>   include/sound/rt5651.h|  7 
>>   sound/soc/codecs/rt5651.c | 91
>> +--
>>   sound/soc/codecs/rt5651.h |  3 ++
>>   3 files changed, 99 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/sound/rt5651.h b/include/sound/rt5651.h
>> index d35de758dfb5..c563383149c4 100644
>> --- a/include/sound/rt5651.h
>> +++ b/include/sound/rt5651.h
>> @@ -11,11 +11,18 @@
>>   #ifndef __LINUX_SND_RT5651_H
>>   #define __LINUX_SND_RT5651_H
>>   +enum rt5651_jd_src {
>> +   RT5651_JD_NULL,
>> +   RT5651_JD1_1,
>> +};
>> +
>>   struct rt5651_platform_data {
>> /* IN2 can optionally be differential */
>> bool in2_diff;
>> bool dmic_en;
>> +
>> +   enum rt5651_jd_src jd_src;
>
>
> I don't see code that sets this platform data, is there a quirk or
> of_property missing in this patchset?

Yes, it is supposed to be enabled by a quirk. In general (personal
taste) I prefer to post the quirk enabling code after the base code
has been ACKed. If you feel like it I can post also the quirk code
together with the next respin of this patchset.

Thank you,

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


[PATCH 0/2] rt5651: Enable jack detection

2017-10-19 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Small set of patches to enable jack detection for the rt5651 codec.

Please note that:
- The jack detection is restricted to the JD1_1 pin only (the only
  hardware I have uses this pin for jack detection)
- AFAICT (reading the rt5651 datasheet) there is no way to detect
  runtime the type of the jack inserted as done for the others rt56*
  codecs, so in the driver I always assume that we are dealing with an
  headset.

Carlo Caione (2):
  ASoC: rt5651: Enable jack detection on JD1_1
  ASoC: intel: byt: Add headset jack

 include/sound/rt5651.h|  7 +++
 sound/soc/codecs/rt5651.c | 91 ++-
 sound/soc/codecs/rt5651.h |  3 ++
 sound/soc/intel/boards/bytcr_rt5651.c | 24 +
 4 files changed, 123 insertions(+), 2 deletions(-)

-- 
2.14.2



[PATCH 0/2] rt5651: Enable jack detection

2017-10-19 Thread Carlo Caione
From: Carlo Caione 

Small set of patches to enable jack detection for the rt5651 codec.

Please note that:
- The jack detection is restricted to the JD1_1 pin only (the only
  hardware I have uses this pin for jack detection)
- AFAICT (reading the rt5651 datasheet) there is no way to detect
  runtime the type of the jack inserted as done for the others rt56*
  codecs, so in the driver I always assume that we are dealing with an
  headset.

Carlo Caione (2):
  ASoC: rt5651: Enable jack detection on JD1_1
  ASoC: intel: byt: Add headset jack

 include/sound/rt5651.h|  7 +++
 sound/soc/codecs/rt5651.c | 91 ++-
 sound/soc/codecs/rt5651.h |  3 ++
 sound/soc/intel/boards/bytcr_rt5651.c | 24 +
 4 files changed, 123 insertions(+), 2 deletions(-)

-- 
2.14.2



[PATCH 2/2] ASoC: intel: byt: Add headset jack

2017-10-19 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Introduce an headset jack in the machine driver and register it to the
codec driver.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/intel/boards/bytcr_rt5651.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 1dad5c98c9ef..0fc850e20fc0 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -49,6 +49,8 @@ struct byt_rt5651_private {
struct clk *mclk;
 };
 
+static struct snd_soc_jack jack;
+
 static unsigned long byt_rt5651_quirk = BYT_RT5651_DMIC_MAP |
BYT_RT5651_DMIC_EN |
BYT_RT5651_MCLK_EN;
@@ -177,6 +179,17 @@ static const struct snd_kcontrol_new byt_rt5651_controls[] 
= {
SOC_DAPM_PIN_SWITCH("Speaker"),
 };
 
+static struct snd_soc_jack_pin bytcr_jack_pins[] = {
+   {
+   .pin= "Headphone",
+   .mask   = SND_JACK_HEADPHONE,
+   },
+   {
+   .pin= "Headset Mic",
+   .mask   = SND_JACK_MICROPHONE,
+   },
+};
+
 static int byt_rt5651_aif1_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
 {
@@ -244,6 +257,7 @@ static const struct dmi_system_id byt_rt5651_quirk_table[] 
= {
 static int byt_rt5651_init(struct snd_soc_pcm_runtime *runtime)
 {
struct snd_soc_card *card = runtime->card;
+   struct snd_soc_codec *codec = runtime->codec;
struct byt_rt5651_private *priv = snd_soc_card_get_drvdata(card);
const struct snd_soc_dapm_route *custom_map;
int num_routes;
@@ -301,6 +315,16 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
dev_err(card->dev, "unable to set MCLK rate\n");
}
 
+   ret = snd_soc_card_jack_new(runtime->card, "Headset",
+   SND_JACK_HEADSET, ,
+   bytcr_jack_pins, 
ARRAY_SIZE(bytcr_jack_pins));
+   if (ret) {
+   dev_err(runtime->dev, "Headset jack creation failed %d\n", ret);
+   return ret;
+   }
+
+   rt5651_set_jack_detect(codec, );
+
return ret;
 }
 
-- 
2.14.2



[PATCH 2/2] ASoC: intel: byt: Add headset jack

2017-10-19 Thread Carlo Caione
From: Carlo Caione 

Introduce an headset jack in the machine driver and register it to the
codec driver.

Signed-off-by: Carlo Caione 
---
 sound/soc/intel/boards/bytcr_rt5651.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 1dad5c98c9ef..0fc850e20fc0 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -49,6 +49,8 @@ struct byt_rt5651_private {
struct clk *mclk;
 };
 
+static struct snd_soc_jack jack;
+
 static unsigned long byt_rt5651_quirk = BYT_RT5651_DMIC_MAP |
BYT_RT5651_DMIC_EN |
BYT_RT5651_MCLK_EN;
@@ -177,6 +179,17 @@ static const struct snd_kcontrol_new byt_rt5651_controls[] 
= {
SOC_DAPM_PIN_SWITCH("Speaker"),
 };
 
+static struct snd_soc_jack_pin bytcr_jack_pins[] = {
+   {
+   .pin= "Headphone",
+   .mask   = SND_JACK_HEADPHONE,
+   },
+   {
+   .pin= "Headset Mic",
+   .mask   = SND_JACK_MICROPHONE,
+   },
+};
+
 static int byt_rt5651_aif1_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
 {
@@ -244,6 +257,7 @@ static const struct dmi_system_id byt_rt5651_quirk_table[] 
= {
 static int byt_rt5651_init(struct snd_soc_pcm_runtime *runtime)
 {
struct snd_soc_card *card = runtime->card;
+   struct snd_soc_codec *codec = runtime->codec;
struct byt_rt5651_private *priv = snd_soc_card_get_drvdata(card);
const struct snd_soc_dapm_route *custom_map;
int num_routes;
@@ -301,6 +315,16 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
dev_err(card->dev, "unable to set MCLK rate\n");
}
 
+   ret = snd_soc_card_jack_new(runtime->card, "Headset",
+   SND_JACK_HEADSET, ,
+   bytcr_jack_pins, 
ARRAY_SIZE(bytcr_jack_pins));
+   if (ret) {
+   dev_err(runtime->dev, "Headset jack creation failed %d\n", ret);
+   return ret;
+   }
+
+   rt5651_set_jack_detect(codec, );
+
return ret;
 }
 
-- 
2.14.2



[PATCH 1/2] ASoC: rt5651: Enable jack detection on JD1_1

2017-10-19 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Enable jack detection or the RT5651 codec on the JD1_1 pin.
The codec has no means to detect the type of the jack connected so we
assume that the jack is always an headset jack.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 include/sound/rt5651.h|  7 
 sound/soc/codecs/rt5651.c | 91 +--
 sound/soc/codecs/rt5651.h |  3 ++
 3 files changed, 99 insertions(+), 2 deletions(-)

diff --git a/include/sound/rt5651.h b/include/sound/rt5651.h
index d35de758dfb5..c563383149c4 100644
--- a/include/sound/rt5651.h
+++ b/include/sound/rt5651.h
@@ -11,11 +11,18 @@
 #ifndef __LINUX_SND_RT5651_H
 #define __LINUX_SND_RT5651_H
 
+enum rt5651_jd_src {
+   RT5651_JD_NULL,
+   RT5651_JD1_1,
+};
+
 struct rt5651_platform_data {
/* IN2 can optionally be differential */
bool in2_diff;
 
bool dmic_en;
+
+   enum rt5651_jd_src jd_src;
 };
 
 #endif
diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index 28f7210cec91..9bc7f31af1a4 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rl6231.h"
 #include "rt5651.h"
@@ -880,6 +881,9 @@ static const struct snd_soc_dapm_widget 
rt5651_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("PLL1", RT5651_PWR_ANLG2,
RT5651_PWR_PLL_BIT, 0, NULL, 0),
/* Input Side */
+   SND_SOC_DAPM_SUPPLY("JD Power", RT5651_PWR_ANLG2,
+   RT5651_PWM_JD_M_BIT, 0, NULL, 0),
+
/* micbias */
SND_SOC_DAPM_SUPPLY("LDO", RT5651_PWR_ANLG1,
RT5651_PWR_LDO_BIT, 0, NULL, 0),
@@ -1528,6 +1532,8 @@ static int rt5651_set_dai_pll(struct snd_soc_dai *dai, 
int pll_id, int source,
 static int rt5651_set_bias_level(struct snd_soc_codec *codec,
enum snd_soc_bias_level level)
 {
+   struct rt5651_priv *rt5651 = snd_soc_codec_get_drvdata(codec);
+
switch (level) {
case SND_SOC_BIAS_PREPARE:
if (SND_SOC_BIAS_STANDBY == 
snd_soc_codec_get_bias_level(codec)) {
@@ -1556,8 +1562,13 @@ static int rt5651_set_bias_level(struct snd_soc_codec 
*codec,
snd_soc_write(codec, RT5651_PWR_DIG2, 0x);
snd_soc_write(codec, RT5651_PWR_VOL, 0x);
snd_soc_write(codec, RT5651_PWR_MIXER, 0x);
-   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x);
-   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x);
+   if (rt5651->pdata.jd_src) {
+   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x0204);
+   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x0002);
+   } else {
+   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x);
+   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x);
+   }
break;
 
default:
@@ -1570,6 +1581,7 @@ static int rt5651_set_bias_level(struct snd_soc_codec 
*codec,
 static int rt5651_probe(struct snd_soc_codec *codec)
 {
struct rt5651_priv *rt5651 = snd_soc_codec_get_drvdata(codec);
+   struct snd_soc_dapm_context *dapm = snd_soc_codec_get_dapm(codec);
 
rt5651->codec = codec;
 
@@ -1585,6 +1597,13 @@ static int rt5651_probe(struct snd_soc_codec *codec)
 
snd_soc_codec_force_bias_level(codec, SND_SOC_BIAS_OFF);
 
+   if (rt5651->pdata.jd_src) {
+   snd_soc_dapm_force_enable_pin(dapm, "JD Power");
+   snd_soc_dapm_force_enable_pin(dapm, "PLL1");
+   snd_soc_dapm_force_enable_pin(dapm, "LDO");
+   snd_soc_dapm_sync(dapm);
+   }
+
return 0;
 }
 
@@ -1728,6 +1747,42 @@ static int rt5651_parse_dt(struct rt5651_priv *rt5651, 
struct device_node *np)
return 0;
 }
 
+static irqreturn_t rt5651_irq(int irq, void *data)
+{
+   struct rt5651_priv *rt5651 = data;
+   int val, report = 0;
+
+   if (!rt5651->codec)
+   return IRQ_HANDLED;
+
+   switch (rt5651->pdata.jd_src) {
+   case RT5651_JD1_1:
+   val = snd_soc_read(rt5651->codec, RT5651_INT_IRQ_ST) & 0x1000;
+   break;
+   default:
+   return IRQ_HANDLED;
+   }
+
+   if (!val)
+   report = SND_JACK_HEADSET;
+
+   snd_soc_jack_report(rt5651->hp_jack, report, SND_JACK_HEADSET);
+
+   return IRQ_HANDLED;
+}
+
+int rt5651_set_jack_detect(struct snd_soc_codec *codec,
+  struct snd_soc_jack *hp_jack)
+{
+   struct rt5651_priv *rt5651 = snd_soc_codec_get_drvdata(codec);
+
+   rt5651->hp_jack = hp_jack;
+   rt5651_irq(0, rt5651);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(rt5651_set_jack_detect);
+
 static int rt5651_i2c_probe(struct i2c_client *i2c,
const struct i2

[PATCH 1/2] ASoC: rt5651: Enable jack detection on JD1_1

2017-10-19 Thread Carlo Caione
From: Carlo Caione 

Enable jack detection or the RT5651 codec on the JD1_1 pin.
The codec has no means to detect the type of the jack connected so we
assume that the jack is always an headset jack.

Signed-off-by: Carlo Caione 
---
 include/sound/rt5651.h|  7 
 sound/soc/codecs/rt5651.c | 91 +--
 sound/soc/codecs/rt5651.h |  3 ++
 3 files changed, 99 insertions(+), 2 deletions(-)

diff --git a/include/sound/rt5651.h b/include/sound/rt5651.h
index d35de758dfb5..c563383149c4 100644
--- a/include/sound/rt5651.h
+++ b/include/sound/rt5651.h
@@ -11,11 +11,18 @@
 #ifndef __LINUX_SND_RT5651_H
 #define __LINUX_SND_RT5651_H
 
+enum rt5651_jd_src {
+   RT5651_JD_NULL,
+   RT5651_JD1_1,
+};
+
 struct rt5651_platform_data {
/* IN2 can optionally be differential */
bool in2_diff;
 
bool dmic_en;
+
+   enum rt5651_jd_src jd_src;
 };
 
 #endif
diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index 28f7210cec91..9bc7f31af1a4 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rl6231.h"
 #include "rt5651.h"
@@ -880,6 +881,9 @@ static const struct snd_soc_dapm_widget 
rt5651_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("PLL1", RT5651_PWR_ANLG2,
RT5651_PWR_PLL_BIT, 0, NULL, 0),
/* Input Side */
+   SND_SOC_DAPM_SUPPLY("JD Power", RT5651_PWR_ANLG2,
+   RT5651_PWM_JD_M_BIT, 0, NULL, 0),
+
/* micbias */
SND_SOC_DAPM_SUPPLY("LDO", RT5651_PWR_ANLG1,
RT5651_PWR_LDO_BIT, 0, NULL, 0),
@@ -1528,6 +1532,8 @@ static int rt5651_set_dai_pll(struct snd_soc_dai *dai, 
int pll_id, int source,
 static int rt5651_set_bias_level(struct snd_soc_codec *codec,
enum snd_soc_bias_level level)
 {
+   struct rt5651_priv *rt5651 = snd_soc_codec_get_drvdata(codec);
+
switch (level) {
case SND_SOC_BIAS_PREPARE:
if (SND_SOC_BIAS_STANDBY == 
snd_soc_codec_get_bias_level(codec)) {
@@ -1556,8 +1562,13 @@ static int rt5651_set_bias_level(struct snd_soc_codec 
*codec,
snd_soc_write(codec, RT5651_PWR_DIG2, 0x);
snd_soc_write(codec, RT5651_PWR_VOL, 0x);
snd_soc_write(codec, RT5651_PWR_MIXER, 0x);
-   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x);
-   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x);
+   if (rt5651->pdata.jd_src) {
+   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x0204);
+   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x0002);
+   } else {
+   snd_soc_write(codec, RT5651_PWR_ANLG1, 0x);
+   snd_soc_write(codec, RT5651_PWR_ANLG2, 0x);
+   }
break;
 
default:
@@ -1570,6 +1581,7 @@ static int rt5651_set_bias_level(struct snd_soc_codec 
*codec,
 static int rt5651_probe(struct snd_soc_codec *codec)
 {
struct rt5651_priv *rt5651 = snd_soc_codec_get_drvdata(codec);
+   struct snd_soc_dapm_context *dapm = snd_soc_codec_get_dapm(codec);
 
rt5651->codec = codec;
 
@@ -1585,6 +1597,13 @@ static int rt5651_probe(struct snd_soc_codec *codec)
 
snd_soc_codec_force_bias_level(codec, SND_SOC_BIAS_OFF);
 
+   if (rt5651->pdata.jd_src) {
+   snd_soc_dapm_force_enable_pin(dapm, "JD Power");
+   snd_soc_dapm_force_enable_pin(dapm, "PLL1");
+   snd_soc_dapm_force_enable_pin(dapm, "LDO");
+   snd_soc_dapm_sync(dapm);
+   }
+
return 0;
 }
 
@@ -1728,6 +1747,42 @@ static int rt5651_parse_dt(struct rt5651_priv *rt5651, 
struct device_node *np)
return 0;
 }
 
+static irqreturn_t rt5651_irq(int irq, void *data)
+{
+   struct rt5651_priv *rt5651 = data;
+   int val, report = 0;
+
+   if (!rt5651->codec)
+   return IRQ_HANDLED;
+
+   switch (rt5651->pdata.jd_src) {
+   case RT5651_JD1_1:
+   val = snd_soc_read(rt5651->codec, RT5651_INT_IRQ_ST) & 0x1000;
+   break;
+   default:
+   return IRQ_HANDLED;
+   }
+
+   if (!val)
+   report = SND_JACK_HEADSET;
+
+   snd_soc_jack_report(rt5651->hp_jack, report, SND_JACK_HEADSET);
+
+   return IRQ_HANDLED;
+}
+
+int rt5651_set_jack_detect(struct snd_soc_codec *codec,
+  struct snd_soc_jack *hp_jack)
+{
+   struct rt5651_priv *rt5651 = snd_soc_codec_get_drvdata(codec);
+
+   rt5651->hp_jack = hp_jack;
+   rt5651_irq(0, rt5651);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(rt5651_set_jack_detect);
+
 static int rt5651_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
 {
@@ -1779,6 +1834,38 @@

[PATCH] ASoC: rt5651: Convert rt5651 micbias1 to a supply widget

2017-10-18 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

MICBIAS widget type has been deprecated. Convert it to a SUPPLY widget.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/codecs/rt5651.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index da60b28ba3df..28f7210cec91 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -883,8 +883,8 @@ static const struct snd_soc_dapm_widget 
rt5651_dapm_widgets[] = {
/* micbias */
SND_SOC_DAPM_SUPPLY("LDO", RT5651_PWR_ANLG1,
RT5651_PWR_LDO_BIT, 0, NULL, 0),
-   SND_SOC_DAPM_MICBIAS("micbias1", RT5651_PWR_ANLG2,
-   RT5651_PWR_MB1_BIT, 0),
+   SND_SOC_DAPM_SUPPLY("micbias1", RT5651_PWR_ANLG2,
+   RT5651_PWR_MB1_BIT, 0, NULL, 0),
/* Input Lines */
SND_SOC_DAPM_INPUT("MIC1"),
SND_SOC_DAPM_INPUT("MIC2"),
-- 
2.14.2



[PATCH] ASoC: rt5651: Convert rt5651 micbias1 to a supply widget

2017-10-18 Thread Carlo Caione
From: Carlo Caione 

MICBIAS widget type has been deprecated. Convert it to a SUPPLY widget.

Signed-off-by: Carlo Caione 
---
 sound/soc/codecs/rt5651.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c
index da60b28ba3df..28f7210cec91 100644
--- a/sound/soc/codecs/rt5651.c
+++ b/sound/soc/codecs/rt5651.c
@@ -883,8 +883,8 @@ static const struct snd_soc_dapm_widget 
rt5651_dapm_widgets[] = {
/* micbias */
SND_SOC_DAPM_SUPPLY("LDO", RT5651_PWR_ANLG1,
RT5651_PWR_LDO_BIT, 0, NULL, 0),
-   SND_SOC_DAPM_MICBIAS("micbias1", RT5651_PWR_ANLG2,
-   RT5651_PWR_MB1_BIT, 0),
+   SND_SOC_DAPM_SUPPLY("micbias1", RT5651_PWR_ANLG2,
+   RT5651_PWR_MB1_BIT, 0, NULL, 0),
/* Input Lines */
SND_SOC_DAPM_INPUT("MIC1"),
SND_SOC_DAPM_INPUT("MIC2"),
-- 
2.14.2



[PATCH] SoC: intel: byt: Introduce new custom IN2 map

2017-10-18 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Introduce a new custom dapm routes map to quirk platforms with the
internal mic connected to IN2P.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/intel/boards/bytcr_rt5651.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 3076bfc0db5e..1dad5c98c9ef 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -37,6 +37,7 @@
 enum {
BYT_RT5651_DMIC_MAP,
BYT_RT5651_IN1_MAP,
+   BYT_RT5651_IN2_MAP,
 };
 
 #define BYT_RT5651_MAP(quirk)  ((quirk) & GENMASK(7, 0))
@@ -58,6 +59,8 @@ static void log_quirks(struct device *dev)
dev_info(dev, "quirk DMIC_MAP enabled");
if (BYT_RT5651_MAP(byt_rt5651_quirk) == BYT_RT5651_IN1_MAP)
dev_info(dev, "quirk IN1_MAP enabled");
+   if (BYT_RT5651_MAP(byt_rt5651_quirk) == BYT_RT5651_IN2_MAP)
+   dev_info(dev, "quirk IN2_MAP enabled");
if (byt_rt5651_quirk & BYT_RT5651_DMIC_EN)
dev_info(dev, "quirk DMIC enabled");
if (byt_rt5651_quirk & BYT_RT5651_MCLK_EN)
@@ -143,7 +146,6 @@ static const struct snd_soc_dapm_route 
byt_rt5651_audio_map[] = {
{"ssp2 Rx", NULL, "AIF1 Capture"},
 
{"Headset Mic", NULL, "micbias1"}, /* lowercase for rt5651 */
-   {"IN2P", NULL, "Headset Mic"},
{"Headphone", NULL, "HPOL"},
{"Headphone", NULL, "HPOR"},
{"Speaker", NULL, "LOUTL"},
@@ -151,15 +153,23 @@ static const struct snd_soc_dapm_route 
byt_rt5651_audio_map[] = {
 };
 
 static const struct snd_soc_dapm_route byt_rt5651_intmic_dmic_map[] = {
+   {"IN2P", NULL, "Headset Mic"},
{"DMIC L1", NULL, "Internal Mic"},
{"DMIC R1", NULL, "Internal Mic"},
 };
 
 static const struct snd_soc_dapm_route byt_rt5651_intmic_in1_map[] = {
{"Internal Mic", NULL, "micbias1"},
+   {"IN2P", NULL, "Headset Mic"},
{"IN1P", NULL, "Internal Mic"},
 };
 
+static const struct snd_soc_dapm_route byt_rt5651_intmic_in2_map[] = {
+   {"Internal Mic", NULL, "micbias1"},
+   {"IN1P", NULL, "Headset Mic"},
+   {"IN2P", NULL, "Internal Mic"},
+};
+
 static const struct snd_kcontrol_new byt_rt5651_controls[] = {
SOC_DAPM_PIN_SWITCH("Headphone"),
SOC_DAPM_PIN_SWITCH("Headset Mic"),
@@ -246,6 +256,10 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
custom_map = byt_rt5651_intmic_in1_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_in1_map);
break;
+   case BYT_RT5651_IN2_MAP:
+   custom_map = byt_rt5651_intmic_in2_map;
+   num_routes = ARRAY_SIZE(byt_rt5651_intmic_in2_map);
+   break;
default:
custom_map = byt_rt5651_intmic_dmic_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_dmic_map);
-- 
2.14.2



[PATCH] SoC: intel: byt: Introduce new custom IN2 map

2017-10-18 Thread Carlo Caione
From: Carlo Caione 

Introduce a new custom dapm routes map to quirk platforms with the
internal mic connected to IN2P.

Signed-off-by: Carlo Caione 
---
 sound/soc/intel/boards/bytcr_rt5651.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 3076bfc0db5e..1dad5c98c9ef 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -37,6 +37,7 @@
 enum {
BYT_RT5651_DMIC_MAP,
BYT_RT5651_IN1_MAP,
+   BYT_RT5651_IN2_MAP,
 };
 
 #define BYT_RT5651_MAP(quirk)  ((quirk) & GENMASK(7, 0))
@@ -58,6 +59,8 @@ static void log_quirks(struct device *dev)
dev_info(dev, "quirk DMIC_MAP enabled");
if (BYT_RT5651_MAP(byt_rt5651_quirk) == BYT_RT5651_IN1_MAP)
dev_info(dev, "quirk IN1_MAP enabled");
+   if (BYT_RT5651_MAP(byt_rt5651_quirk) == BYT_RT5651_IN2_MAP)
+   dev_info(dev, "quirk IN2_MAP enabled");
if (byt_rt5651_quirk & BYT_RT5651_DMIC_EN)
dev_info(dev, "quirk DMIC enabled");
if (byt_rt5651_quirk & BYT_RT5651_MCLK_EN)
@@ -143,7 +146,6 @@ static const struct snd_soc_dapm_route 
byt_rt5651_audio_map[] = {
{"ssp2 Rx", NULL, "AIF1 Capture"},
 
{"Headset Mic", NULL, "micbias1"}, /* lowercase for rt5651 */
-   {"IN2P", NULL, "Headset Mic"},
{"Headphone", NULL, "HPOL"},
{"Headphone", NULL, "HPOR"},
{"Speaker", NULL, "LOUTL"},
@@ -151,15 +153,23 @@ static const struct snd_soc_dapm_route 
byt_rt5651_audio_map[] = {
 };
 
 static const struct snd_soc_dapm_route byt_rt5651_intmic_dmic_map[] = {
+   {"IN2P", NULL, "Headset Mic"},
{"DMIC L1", NULL, "Internal Mic"},
{"DMIC R1", NULL, "Internal Mic"},
 };
 
 static const struct snd_soc_dapm_route byt_rt5651_intmic_in1_map[] = {
{"Internal Mic", NULL, "micbias1"},
+   {"IN2P", NULL, "Headset Mic"},
{"IN1P", NULL, "Internal Mic"},
 };
 
+static const struct snd_soc_dapm_route byt_rt5651_intmic_in2_map[] = {
+   {"Internal Mic", NULL, "micbias1"},
+   {"IN1P", NULL, "Headset Mic"},
+   {"IN2P", NULL, "Internal Mic"},
+};
+
 static const struct snd_kcontrol_new byt_rt5651_controls[] = {
SOC_DAPM_PIN_SWITCH("Headphone"),
SOC_DAPM_PIN_SWITCH("Headset Mic"),
@@ -246,6 +256,10 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
custom_map = byt_rt5651_intmic_in1_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_in1_map);
break;
+   case BYT_RT5651_IN2_MAP:
+   custom_map = byt_rt5651_intmic_in2_map;
+   num_routes = ARRAY_SIZE(byt_rt5651_intmic_in2_map);
+   break;
default:
custom_map = byt_rt5651_intmic_dmic_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_dmic_map);
-- 
2.14.2



Re: [PATCH 0/2] rt5651: Enable platforms with int mic on IN2

2017-10-18 Thread Carlo Caione
On Wed, Oct 18, 2017 at 5:19 PM, Pierre-Louis Bossart
<pierre-louis.boss...@linux.intel.com> wrote:
> On 10/18/17 11:07 AM, Carlo Caione wrote:
>>
>> From: Carlo Caione <ca...@endlessm.com>
>>
>> While working on enabling a cherry-trail laptop shipping the rt5651
>> codec I realized that the machine driver needed some fixup.
>>
>> In particular the laptop I'm working on (KIANO SlimNote 14.2) has the
>> internal mic connected to the IN2 port.
>>
>> All the laptop-specific work with the related quirks will follow.
>
>
> Nice, thanks for the work. You'll have to rebase and resubmit to fix
> conflicts. I provided changes to simplify DMIC quirks (there is a single
> interface, not 2 on this chip) that aren't reflected in your patches and the
> addition of MCLK support. Mark's for-next branch already took the changes
> this morning.

Ups, missed that for a few hours. I'll prepare a new PR.

> Also let me know if you want the UCM files to be updated.

I have a UCM file already that seems to work fine on this laptop. I'll
prepare a PR also for that once all the kernel pieces are in place.

Thank you,

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


Re: [PATCH 0/2] rt5651: Enable platforms with int mic on IN2

2017-10-18 Thread Carlo Caione
On Wed, Oct 18, 2017 at 5:19 PM, Pierre-Louis Bossart
 wrote:
> On 10/18/17 11:07 AM, Carlo Caione wrote:
>>
>> From: Carlo Caione 
>>
>> While working on enabling a cherry-trail laptop shipping the rt5651
>> codec I realized that the machine driver needed some fixup.
>>
>> In particular the laptop I'm working on (KIANO SlimNote 14.2) has the
>> internal mic connected to the IN2 port.
>>
>> All the laptop-specific work with the related quirks will follow.
>
>
> Nice, thanks for the work. You'll have to rebase and resubmit to fix
> conflicts. I provided changes to simplify DMIC quirks (there is a single
> interface, not 2 on this chip) that aren't reflected in your patches and the
> addition of MCLK support. Mark's for-next branch already took the changes
> this morning.

Ups, missed that for a few hours. I'll prepare a new PR.

> Also let me know if you want the UCM files to be updated.

I have a UCM file already that seems to work fine on this laptop. I'll
prepare a PR also for that once all the kernel pieces are in place.

Thank you,

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


[PATCH 0/2] rt5651: Enable platforms with int mic on IN2

2017-10-18 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

While working on enabling a cherry-trail laptop shipping the rt5651
codec I realized that the machine driver needed some fixup.

In particular the laptop I'm working on (KIANO SlimNote 14.2) has the
internal mic connected to the IN2 port.

All the laptop-specific work with the related quirks will follow.

Carlo Caione (2):
  ASoC: intel: byt: Enable quirk logic for custom maps
  ASoC: intel: byt: Introduce new custom IN2 map

 sound/soc/intel/boards/bytcr_rt5651.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

-- 
2.14.2



[PATCH 2/2] ASoC: intel: byt: Introduce new custom IN2 map

2017-10-18 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Introduce a new custom dapm routes map to quirk platforms with the
internal mic connected to IN2P.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/intel/boards/bytcr_rt5651.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index ec84454a232d..a8a9c83dfcc0 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -47,7 +47,6 @@ static const struct snd_soc_dapm_route byt_rt5651_audio_map[] 
= {
{"ssp2 Rx", NULL, "AIF1 Capture"},
 
{"Headset Mic", NULL, "micbias1"}, /* lowercase for rt5651 */
-   {"IN2P", NULL, "Headset Mic"},
{"Headphone", NULL, "HPOL"},
{"Headphone", NULL, "HPOR"},
{"Speaker", NULL, "LOUTL"},
@@ -55,22 +54,32 @@ static const struct snd_soc_dapm_route 
byt_rt5651_audio_map[] = {
 };
 
 static const struct snd_soc_dapm_route byt_rt5651_intmic_dmic1_map[] = {
+   {"IN2P", NULL, "Headset Mic"},
{"DMIC1", NULL, "Internal Mic"},
 };
 
 static const struct snd_soc_dapm_route byt_rt5651_intmic_dmic2_map[] = {
+   {"IN2P", NULL, "Headset Mic"},
{"DMIC2", NULL, "Internal Mic"},
 };
 
 static const struct snd_soc_dapm_route byt_rt5651_intmic_in1_map[] = {
{"Internal Mic", NULL, "micbias1"},
{"IN1P", NULL, "Internal Mic"},
+   {"IN2P", NULL, "Headset Mic"},
+};
+
+static const struct snd_soc_dapm_route byt_rt5651_intmic_in2_map[] = {
+   {"Internal Mic", NULL, "micbias1"},
+   {"IN2P", NULL, "Internal Mic"},
+   {"IN1P", NULL, "Headset Mic"},
 };
 
 enum {
BYT_RT5651_DMIC1_MAP,
BYT_RT5651_DMIC2_MAP,
BYT_RT5651_IN1_MAP,
+   BYT_RT5651_IN2_MAP,
 };
 
 #define BYT_RT5651_MAP(quirk)  ((quirk) & 0xff)
@@ -133,6 +142,10 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
custom_map = byt_rt5651_intmic_in1_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_in1_map);
break;
+   case BYT_RT5651_IN2_MAP:
+   custom_map = byt_rt5651_intmic_in2_map;
+   num_routes = ARRAY_SIZE(byt_rt5651_intmic_in2_map);
+   break;
case BYT_RT5651_DMIC2_MAP:
custom_map = byt_rt5651_intmic_dmic2_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_dmic2_map);
-- 
2.14.2



[PATCH 2/2] ASoC: intel: byt: Introduce new custom IN2 map

2017-10-18 Thread Carlo Caione
From: Carlo Caione 

Introduce a new custom dapm routes map to quirk platforms with the
internal mic connected to IN2P.

Signed-off-by: Carlo Caione 
---
 sound/soc/intel/boards/bytcr_rt5651.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index ec84454a232d..a8a9c83dfcc0 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -47,7 +47,6 @@ static const struct snd_soc_dapm_route byt_rt5651_audio_map[] 
= {
{"ssp2 Rx", NULL, "AIF1 Capture"},
 
{"Headset Mic", NULL, "micbias1"}, /* lowercase for rt5651 */
-   {"IN2P", NULL, "Headset Mic"},
{"Headphone", NULL, "HPOL"},
{"Headphone", NULL, "HPOR"},
{"Speaker", NULL, "LOUTL"},
@@ -55,22 +54,32 @@ static const struct snd_soc_dapm_route 
byt_rt5651_audio_map[] = {
 };
 
 static const struct snd_soc_dapm_route byt_rt5651_intmic_dmic1_map[] = {
+   {"IN2P", NULL, "Headset Mic"},
{"DMIC1", NULL, "Internal Mic"},
 };
 
 static const struct snd_soc_dapm_route byt_rt5651_intmic_dmic2_map[] = {
+   {"IN2P", NULL, "Headset Mic"},
{"DMIC2", NULL, "Internal Mic"},
 };
 
 static const struct snd_soc_dapm_route byt_rt5651_intmic_in1_map[] = {
{"Internal Mic", NULL, "micbias1"},
{"IN1P", NULL, "Internal Mic"},
+   {"IN2P", NULL, "Headset Mic"},
+};
+
+static const struct snd_soc_dapm_route byt_rt5651_intmic_in2_map[] = {
+   {"Internal Mic", NULL, "micbias1"},
+   {"IN2P", NULL, "Internal Mic"},
+   {"IN1P", NULL, "Headset Mic"},
 };
 
 enum {
BYT_RT5651_DMIC1_MAP,
BYT_RT5651_DMIC2_MAP,
BYT_RT5651_IN1_MAP,
+   BYT_RT5651_IN2_MAP,
 };
 
 #define BYT_RT5651_MAP(quirk)  ((quirk) & 0xff)
@@ -133,6 +142,10 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
custom_map = byt_rt5651_intmic_in1_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_in1_map);
break;
+   case BYT_RT5651_IN2_MAP:
+   custom_map = byt_rt5651_intmic_in2_map;
+   num_routes = ARRAY_SIZE(byt_rt5651_intmic_in2_map);
+   break;
case BYT_RT5651_DMIC2_MAP:
custom_map = byt_rt5651_intmic_dmic2_map;
num_routes = ARRAY_SIZE(byt_rt5651_intmic_dmic2_map);
-- 
2.14.2



[PATCH 0/2] rt5651: Enable platforms with int mic on IN2

2017-10-18 Thread Carlo Caione
From: Carlo Caione 

While working on enabling a cherry-trail laptop shipping the rt5651
codec I realized that the machine driver needed some fixup.

In particular the laptop I'm working on (KIANO SlimNote 14.2) has the
internal mic connected to the IN2 port.

All the laptop-specific work with the related quirks will follow.

Carlo Caione (2):
  ASoC: intel: byt: Enable quirk logic for custom maps
  ASoC: intel: byt: Introduce new custom IN2 map

 sound/soc/intel/boards/bytcr_rt5651.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

-- 
2.14.2



[PATCH 1/2] ASoC: intel: byt: Enable quirk logic for custom maps

2017-10-18 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Enable again the quirk logic for the custom dapm routes.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 sound/soc/intel/boards/bytcr_rt5651.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 4a3516b38c2c..ec84454a232d 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -142,6 +142,12 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
num_routes = ARRAY_SIZE(byt_rt5651_intmic_dmic1_map);
}
 
+   ret = snd_soc_dapm_add_routes(>dapm, custom_map, num_routes);
+   if (ret) {
+   dev_err(card->dev, "unable to add custom routes map\n");
+   return ret;
+   }
+
ret = snd_soc_add_card_controls(card, byt_rt5651_controls,
ARRAY_SIZE(byt_rt5651_controls));
if (ret) {
-- 
2.14.2



[PATCH 1/2] ASoC: intel: byt: Enable quirk logic for custom maps

2017-10-18 Thread Carlo Caione
From: Carlo Caione 

Enable again the quirk logic for the custom dapm routes.

Signed-off-by: Carlo Caione 
---
 sound/soc/intel/boards/bytcr_rt5651.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 4a3516b38c2c..ec84454a232d 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -142,6 +142,12 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime 
*runtime)
num_routes = ARRAY_SIZE(byt_rt5651_intmic_dmic1_map);
}
 
+   ret = snd_soc_dapm_add_routes(>dapm, custom_map, num_routes);
+   if (ret) {
+   dev_err(card->dev, "unable to add custom routes map\n");
+   return ret;
+   }
+
ret = snd_soc_add_card_controls(card, byt_rt5651_controls,
ARRAY_SIZE(byt_rt5651_controls));
if (ret) {
-- 
2.14.2



Re: [PATCH RESEND] X.509: Recognize the legacy OID 1.3.14.3.2.29 (sha1WithRSASignature)

2017-09-07 Thread Carlo Caione
On Mon, Aug 21, 2017 at 9:27 AM, Carlo Caione <ca...@caione.org> wrote:
> On Mon, Aug 7, 2017 at 10:01 AM, Carlo Caione <ca...@caione.org> wrote:
>> From: Carlo Caione <ca...@endlessm.com>
>>
>> We have found some ACER laptops shipping with certificates signed using
>> the 1.3.14.3.2.29 OID. This is causing the message
> /cut
>
> Ping on this (literally) two lines patch.

any feedback on this small patch?

-- 
Carlo Caione


Re: [PATCH RESEND] X.509: Recognize the legacy OID 1.3.14.3.2.29 (sha1WithRSASignature)

2017-09-07 Thread Carlo Caione
On Mon, Aug 21, 2017 at 9:27 AM, Carlo Caione  wrote:
> On Mon, Aug 7, 2017 at 10:01 AM, Carlo Caione  wrote:
>> From: Carlo Caione 
>>
>> We have found some ACER laptops shipping with certificates signed using
>> the 1.3.14.3.2.29 OID. This is causing the message
> /cut
>
> Ping on this (literally) two lines patch.

any feedback on this small patch?

-- 
Carlo Caione


Re: [PATCH RESEND] X.509: Recognize the legacy OID 1.3.14.3.2.29 (sha1WithRSASignature)

2017-08-21 Thread Carlo Caione
On Mon, Aug 7, 2017 at 10:01 AM, Carlo Caione <ca...@caione.org> wrote:
> From: Carlo Caione <ca...@endlessm.com>
>
> We have found some ACER laptops shipping with certificates signed using
> the 1.3.14.3.2.29 OID. This is causing the message
/cut

Ping on this (literally) two lines patch.

-- 
Carlo Caione


Re: [PATCH RESEND] X.509: Recognize the legacy OID 1.3.14.3.2.29 (sha1WithRSASignature)

2017-08-21 Thread Carlo Caione
On Mon, Aug 7, 2017 at 10:01 AM, Carlo Caione  wrote:
> From: Carlo Caione 
>
> We have found some ACER laptops shipping with certificates signed using
> the 1.3.14.3.2.29 OID. This is causing the message
/cut

Ping on this (literally) two lines patch.

-- 
Carlo Caione


[PATCH RESEND] X.509: Recognize the legacy OID 1.3.14.3.2.29 (sha1WithRSASignature)

2017-08-07 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

We have found some ACER laptops shipping with certificates signed using
the 1.3.14.3.2.29 OID. This is causing the message

   EFI: Problem loading in-kernel X.509 certificate (-65)

to be printed at boot.

This OID is Rivest, Shamir and Adleman (RSA) algorithm that uses the
Secure Hash Algorithm 1 (SHA1) (obsolete), usually referred to as
sha1WithRSASignature.

sha1WithRSASignature is a deprecated equivalent of
sha1WithRSAEncryption. It originates from the NIST Open Systems
Environment (OSE) Implementor's Workshop (OIW).

It is supported for compatibility with Microsoft's certificate APIs
and tools, particularly makecert.exe, which default(ed/s) to this
OID for SHA-1.

We introduce sha1WithRSASignature as new supported OID making it
equivalent to sha1WithRSAEncryption. This is solving the issue when
loading the in-kernel X.509 certificates that can now be correctly read.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 crypto/asymmetric_keys/x509_cert_parser.c | 1 +
 include/linux/oid_registry.h  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
b/crypto/asymmetric_keys/x509_cert_parser.c
index dd03fead1ca3..cdbc8c2def79 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -203,6 +203,7 @@ int x509_note_pkey_algo(void *context, size_t hdrlen,
break;
 
case OID_sha1WithRSAEncryption:
+   case OID_sha1WithRSASignature:
ctx->cert->sig->hash_algo = "sha1";
ctx->cert->sig->pkey_algo = "rsa";
break;
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index d2fa9ca42e9a..26faee80357f 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -62,6 +62,7 @@ enum OID {
 
OID_certAuthInfoAccess, /* 1.3.6.1.5.5.7.1.1 */
OID_sha1,   /* 1.3.14.3.2.26 */
+   OID_sha1WithRSASignature,   /* 1.3.14.3.2.29 */
OID_sha256, /* 2.16.840.1.101.3.4.2.1 */
OID_sha384, /* 2.16.840.1.101.3.4.2.2 */
OID_sha512, /* 2.16.840.1.101.3.4.2.3 */
-- 
2.13.3



[PATCH RESEND] X.509: Recognize the legacy OID 1.3.14.3.2.29 (sha1WithRSASignature)

2017-08-07 Thread Carlo Caione
From: Carlo Caione 

We have found some ACER laptops shipping with certificates signed using
the 1.3.14.3.2.29 OID. This is causing the message

   EFI: Problem loading in-kernel X.509 certificate (-65)

to be printed at boot.

This OID is Rivest, Shamir and Adleman (RSA) algorithm that uses the
Secure Hash Algorithm 1 (SHA1) (obsolete), usually referred to as
sha1WithRSASignature.

sha1WithRSASignature is a deprecated equivalent of
sha1WithRSAEncryption. It originates from the NIST Open Systems
Environment (OSE) Implementor's Workshop (OIW).

It is supported for compatibility with Microsoft's certificate APIs
and tools, particularly makecert.exe, which default(ed/s) to this
OID for SHA-1.

We introduce sha1WithRSASignature as new supported OID making it
equivalent to sha1WithRSAEncryption. This is solving the issue when
loading the in-kernel X.509 certificates that can now be correctly read.

Signed-off-by: Carlo Caione 
---
 crypto/asymmetric_keys/x509_cert_parser.c | 1 +
 include/linux/oid_registry.h  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
b/crypto/asymmetric_keys/x509_cert_parser.c
index dd03fead1ca3..cdbc8c2def79 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -203,6 +203,7 @@ int x509_note_pkey_algo(void *context, size_t hdrlen,
break;
 
case OID_sha1WithRSAEncryption:
+   case OID_sha1WithRSASignature:
ctx->cert->sig->hash_algo = "sha1";
ctx->cert->sig->pkey_algo = "rsa";
break;
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index d2fa9ca42e9a..26faee80357f 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -62,6 +62,7 @@ enum OID {
 
OID_certAuthInfoAccess, /* 1.3.6.1.5.5.7.1.1 */
OID_sha1,   /* 1.3.14.3.2.26 */
+   OID_sha1WithRSASignature,   /* 1.3.14.3.2.29 */
OID_sha256, /* 2.16.840.1.101.3.4.2.1 */
OID_sha384, /* 2.16.840.1.101.3.4.2.2 */
OID_sha512, /* 2.16.840.1.101.3.4.2.3 */
-- 
2.13.3



[PATCH] X.509: Recognize the legacy OID 1.3.14.3.2.29 (sha1WithRSASignature)

2017-08-01 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

sha1WithRSASignature is a deprecated equivalent of
sha1WithRSAEncryption. It originates from the NIST Open Systems
Environment (OSE) Implementor's Workshop (OIW).

It is supported for compatibility with Microsoft's certificate APIs
and tools, particularly makecert.exe, which default(ed/s) to this
OID for SHA-1.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 crypto/asymmetric_keys/x509_cert_parser.c | 1 +
 include/linux/oid_registry.h  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
b/crypto/asymmetric_keys/x509_cert_parser.c
index dd03fead1ca3..cdbc8c2def79 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -203,6 +203,7 @@ int x509_note_pkey_algo(void *context, size_t hdrlen,
break;
 
case OID_sha1WithRSAEncryption:
+   case OID_sha1WithRSASignature:
ctx->cert->sig->hash_algo = "sha1";
ctx->cert->sig->pkey_algo = "rsa";
break;
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index d2fa9ca42e9a..26faee80357f 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -62,6 +62,7 @@ enum OID {
 
OID_certAuthInfoAccess, /* 1.3.6.1.5.5.7.1.1 */
OID_sha1,   /* 1.3.14.3.2.26 */
+   OID_sha1WithRSASignature,   /* 1.3.14.3.2.29 */
OID_sha256, /* 2.16.840.1.101.3.4.2.1 */
OID_sha384, /* 2.16.840.1.101.3.4.2.2 */
OID_sha512, /* 2.16.840.1.101.3.4.2.3 */
-- 
2.13.3



[PATCH] X.509: Recognize the legacy OID 1.3.14.3.2.29 (sha1WithRSASignature)

2017-08-01 Thread Carlo Caione
From: Carlo Caione 

sha1WithRSASignature is a deprecated equivalent of
sha1WithRSAEncryption. It originates from the NIST Open Systems
Environment (OSE) Implementor's Workshop (OIW).

It is supported for compatibility with Microsoft's certificate APIs
and tools, particularly makecert.exe, which default(ed/s) to this
OID for SHA-1.

Signed-off-by: Carlo Caione 
---
 crypto/asymmetric_keys/x509_cert_parser.c | 1 +
 include/linux/oid_registry.h  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
b/crypto/asymmetric_keys/x509_cert_parser.c
index dd03fead1ca3..cdbc8c2def79 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -203,6 +203,7 @@ int x509_note_pkey_algo(void *context, size_t hdrlen,
break;
 
case OID_sha1WithRSAEncryption:
+   case OID_sha1WithRSASignature:
ctx->cert->sig->hash_algo = "sha1";
ctx->cert->sig->pkey_algo = "rsa";
break;
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index d2fa9ca42e9a..26faee80357f 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -62,6 +62,7 @@ enum OID {
 
OID_certAuthInfoAccess, /* 1.3.6.1.5.5.7.1.1 */
OID_sha1,   /* 1.3.14.3.2.26 */
+   OID_sha1WithRSASignature,   /* 1.3.14.3.2.29 */
OID_sha256, /* 2.16.840.1.101.3.4.2.1 */
OID_sha384, /* 2.16.840.1.101.3.4.2.2 */
OID_sha512, /* 2.16.840.1.101.3.4.2.3 */
-- 
2.13.3



[PATCH] HID: asus: Stop underlying hardware on remove

2017-05-30 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

We are missing a call to hid_hw_stop() on the remove hook.
Among other things this is causing an Oops when (re-)starting GNOME /
upowerd / ... after the module has been already rmmod-ed.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 drivers/hid/hid-asus.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 16df6cc..2e9642d 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -536,6 +536,8 @@ static void asus_remove(struct hid_device *hdev)
drvdata->kbd_backlight->removed = true;
cancel_work_sync(>kbd_backlight->work);
}
+
+   hid_hw_stop(hdev);
 }
 
 static __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
-- 
2.9.3



[PATCH] HID: asus: Stop underlying hardware on remove

2017-05-30 Thread Carlo Caione
From: Carlo Caione 

We are missing a call to hid_hw_stop() on the remove hook.
Among other things this is causing an Oops when (re-)starting GNOME /
upowerd / ... after the module has been already rmmod-ed.

Signed-off-by: Carlo Caione 
---
 drivers/hid/hid-asus.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 16df6cc..2e9642d 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -536,6 +536,8 @@ static void asus_remove(struct hid_device *hdev)
drvdata->kbd_backlight->removed = true;
cancel_work_sync(>kbd_backlight->work);
}
+
+   hid_hw_stop(hdev);
 }
 
 static __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
-- 
2.9.3



Re: [PATCH v2 00/18] ARM64: meson: DT cleanups

2017-05-25 Thread Carlo Caione
On Sat, May 20, 2017 at 3:16 PM, Andreas Färber <afaer...@suse.de> wrote:
> Hi Kevin,
>

/snip

> We can certainly argue who started which tone here. From my perspective
> I kindly asked Jerome to fix his node order on IRC, he said okay, but
> neither he nor any of you ever sent such patches. (This was back when we
> had an actual mismerge.) Weeks later I grudgingly sent the v1 cleanup
> series myself, but instead of thanking me for doing "your" work, I was
> greeted with unfriendly opposition and - yes, frustratingly is a word
> here - put my efforts elsewhere. Neil's actions - who is neither author
> nor maintainer here - of copying an opinionated personal and partially

Uhm, probably we can fix at least this by making Neil maintainer
instead of me given that Neil and BayLibre did much of the work on
this platform.

-- 
Carlo Caione


Re: [PATCH v2 00/18] ARM64: meson: DT cleanups

2017-05-25 Thread Carlo Caione
On Sat, May 20, 2017 at 3:16 PM, Andreas Färber  wrote:
> Hi Kevin,
>

/snip

> We can certainly argue who started which tone here. From my perspective
> I kindly asked Jerome to fix his node order on IRC, he said okay, but
> neither he nor any of you ever sent such patches. (This was back when we
> had an actual mismerge.) Weeks later I grudgingly sent the v1 cleanup
> series myself, but instead of thanking me for doing "your" work, I was
> greeted with unfriendly opposition and - yes, frustratingly is a word
> here - put my efforts elsewhere. Neil's actions - who is neither author
> nor maintainer here - of copying an opinionated personal and partially

Uhm, probably we can fix at least this by making Neil maintainer
instead of me given that Neil and BayLibre did much of the work on
this platform.

-- 
Carlo Caione


Re: [PATCH v1 0/9] platform/x86: hp-wmi: Driver refactoring and cleanups

2017-04-20 Thread Carlo Caione
On Thu, Apr 20, 2017 at 4:25 AM, Darren Hart <dvh...@infradead.org> wrote:
>
> From: "Darren Hart (VMware)" <dvh...@infradead.org>
>
> This series factors out some redundant code, cleans up a number of style 
> issues,
> modernizes the sysfs usage, and cleans up the return paths. All told, the 
> driver
> is reduced in size by 37 lines (3.6%).
>
> I do not have an HP laptop, so I'm hoping Carlo can help out with some 
> testing.
> In particular we need to verify that hotkeys and sysfs continue to work as
> before.

On my HP 240 G5:

Tested-by: Carlo Caione <ca...@endlessm.com>

Cheers,

-- 
Carlo Caione


Re: [PATCH v1 0/9] platform/x86: hp-wmi: Driver refactoring and cleanups

2017-04-20 Thread Carlo Caione
On Thu, Apr 20, 2017 at 4:25 AM, Darren Hart  wrote:
>
> From: "Darren Hart (VMware)" 
>
> This series factors out some redundant code, cleans up a number of style 
> issues,
> modernizes the sysfs usage, and cleans up the return paths. All told, the 
> driver
> is reduced in size by 37 lines (3.6%).
>
> I do not have an HP laptop, so I'm hoping Carlo can help out with some 
> testing.
> In particular we need to verify that hotkeys and sysfs continue to work as
> before.

On my HP 240 G5:

Tested-by: Carlo Caione 

Cheers,

-- 
Carlo Caione


[PATCH] hp-wmi: Do not shadow error values

2017-04-19 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state,
...) using hp_wmi_perform_query to perform an HP WMI query shadow the
returned value in case of error.

We return -EINVAL only when the HP WMI query returns a positive value
(the specific error code) to not mix this up with the actual value
returned by the helper function.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 drivers/platform/x86/hp-wmi.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
index 2b721fd..454cb2e 100644
--- a/drivers/platform/x86/hp-wmi.c
+++ b/drivers/platform/x86/hp-wmi.c
@@ -248,7 +248,7 @@ static int hp_wmi_display_state(void)
int ret = hp_wmi_perform_query(HPWMI_DISPLAY_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -258,7 +258,7 @@ static int hp_wmi_hddtemp_state(void)
int ret = hp_wmi_perform_query(HPWMI_HDDTEMP_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -268,7 +268,7 @@ static int hp_wmi_als_state(void)
int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -279,7 +279,7 @@ static int hp_wmi_dock_state(void)
   sizeof(state), sizeof(state));
 
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
 
return state & 0x1;
 }
@@ -290,7 +290,7 @@ static int hp_wmi_tablet_state(void)
int ret = hp_wmi_perform_query(HPWMI_HARDWARE_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
 
return (state & 0x4) ? 1 : 0;
 }
@@ -323,7 +323,7 @@ static int __init hp_wmi_enable_hotkeys(void)
int ret = hp_wmi_perform_query(HPWMI_BIOS_QUERY, 1, ,
   sizeof(value), 0);
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return 0;
 }
 
@@ -336,7 +336,7 @@ static int hp_wmi_set_block(void *data, bool blocked)
ret = hp_wmi_perform_query(HPWMI_WIRELESS_QUERY, 1,
   , sizeof(query), 0);
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return 0;
 }
 
@@ -428,7 +428,7 @@ static int hp_wmi_post_code_state(void)
int ret = hp_wmi_perform_query(HPWMI_POSTCODEERROR_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -494,7 +494,7 @@ static ssize_t set_als(struct device *dev, struct 
device_attribute *attr,
int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, 1, ,
   sizeof(tmp), sizeof(tmp));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
 
return count;
 }
@@ -515,7 +515,7 @@ static ssize_t set_postcode(struct device *dev, struct 
device_attribute *attr,
ret = hp_wmi_perform_query(HPWMI_POSTCODEERROR_QUERY, 1, ,
   sizeof(tmp), sizeof(tmp));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
 
return count;
 }
-- 
2.9.3



[PATCH] hp-wmi: Do not shadow error values

2017-04-19 Thread Carlo Caione
From: Carlo Caione 

All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state,
...) using hp_wmi_perform_query to perform an HP WMI query shadow the
returned value in case of error.

We return -EINVAL only when the HP WMI query returns a positive value
(the specific error code) to not mix this up with the actual value
returned by the helper function.

Signed-off-by: Carlo Caione 
---
 drivers/platform/x86/hp-wmi.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
index 2b721fd..454cb2e 100644
--- a/drivers/platform/x86/hp-wmi.c
+++ b/drivers/platform/x86/hp-wmi.c
@@ -248,7 +248,7 @@ static int hp_wmi_display_state(void)
int ret = hp_wmi_perform_query(HPWMI_DISPLAY_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -258,7 +258,7 @@ static int hp_wmi_hddtemp_state(void)
int ret = hp_wmi_perform_query(HPWMI_HDDTEMP_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -268,7 +268,7 @@ static int hp_wmi_als_state(void)
int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -279,7 +279,7 @@ static int hp_wmi_dock_state(void)
   sizeof(state), sizeof(state));
 
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
 
return state & 0x1;
 }
@@ -290,7 +290,7 @@ static int hp_wmi_tablet_state(void)
int ret = hp_wmi_perform_query(HPWMI_HARDWARE_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
 
return (state & 0x4) ? 1 : 0;
 }
@@ -323,7 +323,7 @@ static int __init hp_wmi_enable_hotkeys(void)
int ret = hp_wmi_perform_query(HPWMI_BIOS_QUERY, 1, ,
   sizeof(value), 0);
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return 0;
 }
 
@@ -336,7 +336,7 @@ static int hp_wmi_set_block(void *data, bool blocked)
ret = hp_wmi_perform_query(HPWMI_WIRELESS_QUERY, 1,
   , sizeof(query), 0);
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return 0;
 }
 
@@ -428,7 +428,7 @@ static int hp_wmi_post_code_state(void)
int ret = hp_wmi_perform_query(HPWMI_POSTCODEERROR_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -494,7 +494,7 @@ static ssize_t set_als(struct device *dev, struct 
device_attribute *attr,
int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, 1, ,
   sizeof(tmp), sizeof(tmp));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
 
return count;
 }
@@ -515,7 +515,7 @@ static ssize_t set_postcode(struct device *dev, struct 
device_attribute *attr,
ret = hp_wmi_perform_query(HPWMI_POSTCODEERROR_QUERY, 1, ,
   sizeof(tmp), sizeof(tmp));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
 
return count;
 }
-- 
2.9.3



Re: [PATCH v2 1/2] hp-wmi: Do not shadow error values

2017-04-19 Thread Carlo Caione
On Wed, Apr 19, 2017 at 10:11 PM, Darren Hart <dvh...@infradead.org> wrote:
> On Wed, Apr 19, 2017 at 07:41:53PM +0200, Carlo Caione wrote:
>> From: Carlo Caione <ca...@endlessm.com>
>>
>> All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state,
>> ...) using hp_wmi_perform_query to perform an HP WMI query shadow the
>> returned value in case of error.
>>
>> We return -EINVAL only when the HP WMI query returns a positive value
>> (the specific error code) to not mix this up with the actual value
>> returned by the helper function.
>
> So Andy is correct in that we try to avoid shadowing error codes where 
> possible.
> I accepted v1 of this series because it fixed an existing problem in a way
> consistent with the existing code.
>
> Since v1 is already in for-next, let's consider the following a subsequent
> cleanup. Would you please create a new patch to address the shadowing error 
> code
> issues on top of the v1 patch series.

No problem. On its way.

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


Re: [PATCH v2 1/2] hp-wmi: Do not shadow error values

2017-04-19 Thread Carlo Caione
On Wed, Apr 19, 2017 at 10:11 PM, Darren Hart  wrote:
> On Wed, Apr 19, 2017 at 07:41:53PM +0200, Carlo Caione wrote:
>> From: Carlo Caione 
>>
>> All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state,
>> ...) using hp_wmi_perform_query to perform an HP WMI query shadow the
>> returned value in case of error.
>>
>> We return -EINVAL only when the HP WMI query returns a positive value
>> (the specific error code) to not mix this up with the actual value
>> returned by the helper function.
>
> So Andy is correct in that we try to avoid shadowing error codes where 
> possible.
> I accepted v1 of this series because it fixed an existing problem in a way
> consistent with the existing code.
>
> Since v1 is already in for-next, let's consider the following a subsequent
> cleanup. Would you please create a new patch to address the shadowing error 
> code
> issues on top of the v1 patch series.

No problem. On its way.

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


[PATCH v2 0/2] hp-wmi: Fix dock status and tablet mode reporting

2017-04-19 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

Several HP laptops cannot be put to sleep using the LID since systemd complains
that the system is docked even though the laptop is not even dockable (see
[1]).

This is due to a bug in hp-wmi where the driver is failing to check for errors
before creating the input switches.

[1]: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1574120

changelog:

v2:
 * Changed PATCH 1/2 to not shadow negative errors if any

Carlo Caione (2):
  hp-wmi: Do not shadow error values
  hp-wmi: Fix detection for dock and tablet mode

 drivers/platform/x86/hp-wmi.c | 52 +++
 1 file changed, 33 insertions(+), 19 deletions(-)

-- 
2.9.3



[PATCH v2 1/2] hp-wmi: Do not shadow error values

2017-04-19 Thread Carlo Caione
From: Carlo Caione <ca...@endlessm.com>

All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state,
...) using hp_wmi_perform_query to perform an HP WMI query shadow the
returned value in case of error.

We return -EINVAL only when the HP WMI query returns a positive value
(the specific error code) to not mix this up with the actual value
returned by the helper function.

Signed-off-by: Carlo Caione <ca...@endlessm.com>
---
 drivers/platform/x86/hp-wmi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
index 96ffda4..8c7773a 100644
--- a/drivers/platform/x86/hp-wmi.c
+++ b/drivers/platform/x86/hp-wmi.c
@@ -248,7 +248,7 @@ static int hp_wmi_display_state(void)
int ret = hp_wmi_perform_query(HPWMI_DISPLAY_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -258,7 +258,7 @@ static int hp_wmi_hddtemp_state(void)
int ret = hp_wmi_perform_query(HPWMI_HDDTEMP_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -268,7 +268,7 @@ static int hp_wmi_als_state(void)
int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -279,7 +279,7 @@ static int hp_wmi_dock_state(void)
   sizeof(state), sizeof(state));
 
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
 
return state & 0x1;
 }
@@ -290,7 +290,7 @@ static int hp_wmi_tablet_state(void)
int ret = hp_wmi_perform_query(HPWMI_HARDWARE_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return ret;
+   return ret < 0 ? ret : -EINVAL;
 
return (state & 0x4) ? 1 : 0;
 }
@@ -323,7 +323,7 @@ static int __init hp_wmi_enable_hotkeys(void)
int ret = hp_wmi_perform_query(HPWMI_BIOS_QUERY, 1, ,
   sizeof(value), 0);
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return 0;
 }
 
-- 
2.9.3



[PATCH v2 0/2] hp-wmi: Fix dock status and tablet mode reporting

2017-04-19 Thread Carlo Caione
From: Carlo Caione 

Several HP laptops cannot be put to sleep using the LID since systemd complains
that the system is docked even though the laptop is not even dockable (see
[1]).

This is due to a bug in hp-wmi where the driver is failing to check for errors
before creating the input switches.

[1]: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1574120

changelog:

v2:
 * Changed PATCH 1/2 to not shadow negative errors if any

Carlo Caione (2):
  hp-wmi: Do not shadow error values
  hp-wmi: Fix detection for dock and tablet mode

 drivers/platform/x86/hp-wmi.c | 52 +++
 1 file changed, 33 insertions(+), 19 deletions(-)

-- 
2.9.3



[PATCH v2 1/2] hp-wmi: Do not shadow error values

2017-04-19 Thread Carlo Caione
From: Carlo Caione 

All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state,
...) using hp_wmi_perform_query to perform an HP WMI query shadow the
returned value in case of error.

We return -EINVAL only when the HP WMI query returns a positive value
(the specific error code) to not mix this up with the actual value
returned by the helper function.

Signed-off-by: Carlo Caione 
---
 drivers/platform/x86/hp-wmi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
index 96ffda4..8c7773a 100644
--- a/drivers/platform/x86/hp-wmi.c
+++ b/drivers/platform/x86/hp-wmi.c
@@ -248,7 +248,7 @@ static int hp_wmi_display_state(void)
int ret = hp_wmi_perform_query(HPWMI_DISPLAY_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -258,7 +258,7 @@ static int hp_wmi_hddtemp_state(void)
int ret = hp_wmi_perform_query(HPWMI_HDDTEMP_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -268,7 +268,7 @@ static int hp_wmi_als_state(void)
int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return state;
 }
 
@@ -279,7 +279,7 @@ static int hp_wmi_dock_state(void)
   sizeof(state), sizeof(state));
 
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
 
return state & 0x1;
 }
@@ -290,7 +290,7 @@ static int hp_wmi_tablet_state(void)
int ret = hp_wmi_perform_query(HPWMI_HARDWARE_QUERY, 0, ,
   sizeof(state), sizeof(state));
if (ret)
-   return ret;
+   return ret < 0 ? ret : -EINVAL;
 
return (state & 0x4) ? 1 : 0;
 }
@@ -323,7 +323,7 @@ static int __init hp_wmi_enable_hotkeys(void)
int ret = hp_wmi_perform_query(HPWMI_BIOS_QUERY, 1, ,
   sizeof(value), 0);
if (ret)
-   return -EINVAL;
+   return ret < 0 ? ret : -EINVAL;
return 0;
 }
 
-- 
2.9.3



  1   2   3   >