Re: [PATCH v2] iio: humidity: hts221: Fix sensor reads after resume

2018-06-30 Thread Shrirang Bagul
On Thu, 2018-06-28 at 11:05 +0200, Lorenzo Bianconi wrote:
> > AV_CONF register (RH & TEMP. oversampling ratio's) and CTRL1 register
> > (ODR & BDU settings) values are lost after suspend.
> > 
> > While the change in AV_CONF updates the sensor resolution modes
> > (overriding the user configuration before the device went to suspend);
> > loss of the contents of the CTRL1 register leads to failure in reading
> > sensor output.
> > 
> > This patch restores the AV_CONF & CTRL1 registers after resume.
> > 
> 
> Hi Shrirang,
> 
> I still suspect we have some hw issue (IoT Gateway) here (cc ST folks
> to get more info) and anyway I guess the proposed patch will fix the issue
> completely since OD and HL configuration is not restored properly.
> Could you please double check HL/OD regs are properly preserved after resume
> phase?
Yes, certainly. Will include the i2c register dumps before and after the resume 
to support
the patch.

Regards,
Shrirang
> 
> Regards,
> Lorenzo
> 
> > Changes from v1:
> > - Don't drop enabling the sensor during resume
> > - Restore AV_CONF register along with CTRL1
> >   (As demonstrated with i2c register dumps of hts221 captured on Dell
> >   IoT Gateways 300x before suspend & after resume [1])
> > 
> > Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR 
> > reconfiguration)
> > Signed-off-by: Shrirang Bagul 
> > 
> > [v1] https://marc.info/?l=linux-iio=152506543000442=2
> > [1] https://marc.info/?l=linux-iio=152534455701742=2
> > 
> > This patch is based on:
> > git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git -b testing
> > ---
> >  drivers/iio/humidity/hts221_core.c | 31 +-
> >  1 file changed, 30 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/iio/humidity/hts221_core.c 
> > b/drivers/iio/humidity/hts221_core.c
> > index 166946d4978d..fc5599497f55 100644
> > --- a/drivers/iio/humidity/hts221_core.c
> > +++ b/drivers/iio/humidity/hts221_core.c
> > @@ -656,14 +656,43 @@ static int __maybe_unused hts221_resume(struct device 
> > *dev)
> >  {
> > struct iio_dev *iio_dev = dev_get_drvdata(dev);
> > struct hts221_hw *hw = iio_priv(iio_dev);
> > +   const struct hts221_avg *avg;
> > +   u8 data, idx;
> > int err = 0;
> >  
> > +   /* Restore contents of AV_CONF (RH & TEMP. oversampling ratio's) */
> > +   avg = _avg_list[HTS221_SENSOR_H];
> > +   idx = hw->sensors[HTS221_SENSOR_H].cur_avg_idx;
> > +   data = avg->avg_avl[idx];
> > +   err = hts221_update_avg(hw, HTS221_SENSOR_H, data);
> > +   if (err < 0)
> > +   goto fail_err;
> > +
> > +   avg = _avg_list[HTS221_SENSOR_T];
> > +   idx = hw->sensors[HTS221_SENSOR_T].cur_avg_idx;
> > +   data = avg->avg_avl[idx];
> > +   err = hts221_update_avg(hw, HTS221_SENSOR_T, data);
> > +   if (err < 0)
> > +   goto fail_err;
> 
> just return err, no need for goto statement
Okay.
> 
> > +
> > +   /* Restore contents of CTRL1 (BDU & ODR) */
> > +   err = regmap_update_bits(hw->regmap, HTS221_REG_CNTRL1_ADDR,
> > +HTS221_BDU_MASK,
> > +FIELD_PREP(HTS221_BDU_MASK, 1));
> > +   if (err < 0)
> > +   goto fail_err;
> > +
> > +   err = hts221_update_odr(hw, hw->odr);
> > +   if (err < 0)
> > +   goto fail_err;
> > +
> 
> just return err, no need for goto statement
Okay.
> 
> > if (hw->enabled)
> > err = regmap_update_bits(hw->regmap, HTS221_REG_CNTRL1_ADDR,
> >  HTS221_ENABLE_MASK,
> >  FIELD_PREP(HTS221_ENABLE_MASK,
> > true));
> > -   return err;
> > +fail_err:
> > +   return err < 0 ? err : 0;
> >  }
> >  
> >  const struct dev_pm_ops hts221_pm_ops = {
> > -- 
> > 2.17.1
> > 

signature.asc
Description: This is a digitally signed message part


Re: [PATCH v2] iio: humidity: hts221: Fix sensor reads after resume

2018-06-30 Thread Shrirang Bagul
On Thu, 2018-06-28 at 11:05 +0200, Lorenzo Bianconi wrote:
> > AV_CONF register (RH & TEMP. oversampling ratio's) and CTRL1 register
> > (ODR & BDU settings) values are lost after suspend.
> > 
> > While the change in AV_CONF updates the sensor resolution modes
> > (overriding the user configuration before the device went to suspend);
> > loss of the contents of the CTRL1 register leads to failure in reading
> > sensor output.
> > 
> > This patch restores the AV_CONF & CTRL1 registers after resume.
> > 
> 
> Hi Shrirang,
> 
> I still suspect we have some hw issue (IoT Gateway) here (cc ST folks
> to get more info) and anyway I guess the proposed patch will fix the issue
> completely since OD and HL configuration is not restored properly.
> Could you please double check HL/OD regs are properly preserved after resume
> phase?
Yes, certainly. Will include the i2c register dumps before and after the resume 
to support
the patch.

Regards,
Shrirang
> 
> Regards,
> Lorenzo
> 
> > Changes from v1:
> > - Don't drop enabling the sensor during resume
> > - Restore AV_CONF register along with CTRL1
> >   (As demonstrated with i2c register dumps of hts221 captured on Dell
> >   IoT Gateways 300x before suspend & after resume [1])
> > 
> > Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR 
> > reconfiguration)
> > Signed-off-by: Shrirang Bagul 
> > 
> > [v1] https://marc.info/?l=linux-iio=152506543000442=2
> > [1] https://marc.info/?l=linux-iio=152534455701742=2
> > 
> > This patch is based on:
> > git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git -b testing
> > ---
> >  drivers/iio/humidity/hts221_core.c | 31 +-
> >  1 file changed, 30 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/iio/humidity/hts221_core.c 
> > b/drivers/iio/humidity/hts221_core.c
> > index 166946d4978d..fc5599497f55 100644
> > --- a/drivers/iio/humidity/hts221_core.c
> > +++ b/drivers/iio/humidity/hts221_core.c
> > @@ -656,14 +656,43 @@ static int __maybe_unused hts221_resume(struct device 
> > *dev)
> >  {
> > struct iio_dev *iio_dev = dev_get_drvdata(dev);
> > struct hts221_hw *hw = iio_priv(iio_dev);
> > +   const struct hts221_avg *avg;
> > +   u8 data, idx;
> > int err = 0;
> >  
> > +   /* Restore contents of AV_CONF (RH & TEMP. oversampling ratio's) */
> > +   avg = _avg_list[HTS221_SENSOR_H];
> > +   idx = hw->sensors[HTS221_SENSOR_H].cur_avg_idx;
> > +   data = avg->avg_avl[idx];
> > +   err = hts221_update_avg(hw, HTS221_SENSOR_H, data);
> > +   if (err < 0)
> > +   goto fail_err;
> > +
> > +   avg = _avg_list[HTS221_SENSOR_T];
> > +   idx = hw->sensors[HTS221_SENSOR_T].cur_avg_idx;
> > +   data = avg->avg_avl[idx];
> > +   err = hts221_update_avg(hw, HTS221_SENSOR_T, data);
> > +   if (err < 0)
> > +   goto fail_err;
> 
> just return err, no need for goto statement
Okay.
> 
> > +
> > +   /* Restore contents of CTRL1 (BDU & ODR) */
> > +   err = regmap_update_bits(hw->regmap, HTS221_REG_CNTRL1_ADDR,
> > +HTS221_BDU_MASK,
> > +FIELD_PREP(HTS221_BDU_MASK, 1));
> > +   if (err < 0)
> > +   goto fail_err;
> > +
> > +   err = hts221_update_odr(hw, hw->odr);
> > +   if (err < 0)
> > +   goto fail_err;
> > +
> 
> just return err, no need for goto statement
Okay.
> 
> > if (hw->enabled)
> > err = regmap_update_bits(hw->regmap, HTS221_REG_CNTRL1_ADDR,
> >  HTS221_ENABLE_MASK,
> >  FIELD_PREP(HTS221_ENABLE_MASK,
> > true));
> > -   return err;
> > +fail_err:
> > +   return err < 0 ? err : 0;
> >  }
> >  
> >  const struct dev_pm_ops hts221_pm_ops = {
> > -- 
> > 2.17.1
> > 

signature.asc
Description: This is a digitally signed message part


[PATCH v2] iio: humidity: hts221: Fix sensor reads after resume

2018-06-28 Thread Shrirang Bagul
AV_CONF register (RH & TEMP. oversampling ratio's) and CTRL1 register
(ODR & BDU settings) values are lost after suspend.

While the change in AV_CONF updates the sensor resolution modes
(overriding the user configuration before the device went to suspend);
loss of the contents of the CTRL1 register leads to failure in reading
sensor output.

This patch restores the AV_CONF & CTRL1 registers after resume.

Changes from v1:
- Don't drop enabling the sensor during resume
- Restore AV_CONF register along with CTRL1
  (As demonstrated with i2c register dumps of hts221 captured on Dell
  IoT Gateways 300x before suspend & after resume [1])

Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR reconfiguration)
Signed-off-by: Shrirang Bagul 

[v1] https://marc.info/?l=linux-iio=152506543000442=2
[1] https://marc.info/?l=linux-iio=152534455701742=2

This patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git -b testing
---
 drivers/iio/humidity/hts221_core.c | 31 +-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/humidity/hts221_core.c 
b/drivers/iio/humidity/hts221_core.c
index 166946d4978d..fc5599497f55 100644
--- a/drivers/iio/humidity/hts221_core.c
+++ b/drivers/iio/humidity/hts221_core.c
@@ -656,14 +656,43 @@ static int __maybe_unused hts221_resume(struct device 
*dev)
 {
struct iio_dev *iio_dev = dev_get_drvdata(dev);
struct hts221_hw *hw = iio_priv(iio_dev);
+   const struct hts221_avg *avg;
+   u8 data, idx;
int err = 0;
 
+   /* Restore contents of AV_CONF (RH & TEMP. oversampling ratio's) */
+   avg = _avg_list[HTS221_SENSOR_H];
+   idx = hw->sensors[HTS221_SENSOR_H].cur_avg_idx;
+   data = avg->avg_avl[idx];
+   err = hts221_update_avg(hw, HTS221_SENSOR_H, data);
+   if (err < 0)
+   goto fail_err;
+
+   avg = _avg_list[HTS221_SENSOR_T];
+   idx = hw->sensors[HTS221_SENSOR_T].cur_avg_idx;
+   data = avg->avg_avl[idx];
+   err = hts221_update_avg(hw, HTS221_SENSOR_T, data);
+   if (err < 0)
+   goto fail_err;
+
+   /* Restore contents of CTRL1 (BDU & ODR) */
+   err = regmap_update_bits(hw->regmap, HTS221_REG_CNTRL1_ADDR,
+HTS221_BDU_MASK,
+FIELD_PREP(HTS221_BDU_MASK, 1));
+   if (err < 0)
+   goto fail_err;
+
+   err = hts221_update_odr(hw, hw->odr);
+   if (err < 0)
+   goto fail_err;
+
if (hw->enabled)
err = regmap_update_bits(hw->regmap, HTS221_REG_CNTRL1_ADDR,
 HTS221_ENABLE_MASK,
 FIELD_PREP(HTS221_ENABLE_MASK,
true));
-   return err;
+fail_err:
+   return err < 0 ? err : 0;
 }
 
 const struct dev_pm_ops hts221_pm_ops = {
-- 
2.17.1



[PATCH v2] iio: humidity: hts221: Fix sensor reads after resume

2018-06-28 Thread Shrirang Bagul
AV_CONF register (RH & TEMP. oversampling ratio's) and CTRL1 register
(ODR & BDU settings) values are lost after suspend.

While the change in AV_CONF updates the sensor resolution modes
(overriding the user configuration before the device went to suspend);
loss of the contents of the CTRL1 register leads to failure in reading
sensor output.

This patch restores the AV_CONF & CTRL1 registers after resume.

Changes from v1:
- Don't drop enabling the sensor during resume
- Restore AV_CONF register along with CTRL1
  (As demonstrated with i2c register dumps of hts221 captured on Dell
  IoT Gateways 300x before suspend & after resume [1])

Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR reconfiguration)
Signed-off-by: Shrirang Bagul 

[v1] https://marc.info/?l=linux-iio=152506543000442=2
[1] https://marc.info/?l=linux-iio=152534455701742=2

This patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git -b testing
---
 drivers/iio/humidity/hts221_core.c | 31 +-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/humidity/hts221_core.c 
b/drivers/iio/humidity/hts221_core.c
index 166946d4978d..fc5599497f55 100644
--- a/drivers/iio/humidity/hts221_core.c
+++ b/drivers/iio/humidity/hts221_core.c
@@ -656,14 +656,43 @@ static int __maybe_unused hts221_resume(struct device 
*dev)
 {
struct iio_dev *iio_dev = dev_get_drvdata(dev);
struct hts221_hw *hw = iio_priv(iio_dev);
+   const struct hts221_avg *avg;
+   u8 data, idx;
int err = 0;
 
+   /* Restore contents of AV_CONF (RH & TEMP. oversampling ratio's) */
+   avg = _avg_list[HTS221_SENSOR_H];
+   idx = hw->sensors[HTS221_SENSOR_H].cur_avg_idx;
+   data = avg->avg_avl[idx];
+   err = hts221_update_avg(hw, HTS221_SENSOR_H, data);
+   if (err < 0)
+   goto fail_err;
+
+   avg = _avg_list[HTS221_SENSOR_T];
+   idx = hw->sensors[HTS221_SENSOR_T].cur_avg_idx;
+   data = avg->avg_avl[idx];
+   err = hts221_update_avg(hw, HTS221_SENSOR_T, data);
+   if (err < 0)
+   goto fail_err;
+
+   /* Restore contents of CTRL1 (BDU & ODR) */
+   err = regmap_update_bits(hw->regmap, HTS221_REG_CNTRL1_ADDR,
+HTS221_BDU_MASK,
+FIELD_PREP(HTS221_BDU_MASK, 1));
+   if (err < 0)
+   goto fail_err;
+
+   err = hts221_update_odr(hw, hw->odr);
+   if (err < 0)
+   goto fail_err;
+
if (hw->enabled)
err = regmap_update_bits(hw->regmap, HTS221_REG_CNTRL1_ADDR,
 HTS221_ENABLE_MASK,
 FIELD_PREP(HTS221_ENABLE_MASK,
true));
-   return err;
+fail_err:
+   return err < 0 ? err : 0;
 }
 
 const struct dev_pm_ops hts221_pm_ops = {
-- 
2.17.1



Re: [PATCH] iio: humidity: hts221: Fix sensor reads after resume

2018-05-06 Thread Shrirang Bagul
On Sun, 2018-05-06 at 17:19 +0100, Jonathan Cameron wrote:
> On Mon, 30 Apr 2018 12:25:46 +0800
> Shrirang Bagul <shrirang.ba...@canonical.com> wrote:
> 
> > CTRL1 register (ODR & BDU settings) gets reset after system comes back
> > from suspend, causing subsequent reads from the sensor to fail.
> > 
> > This patch restores the CTRL1 register after resume.
> > 
> > Based on:
> > git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git 
> > iio-fixes-for-4.14b
> > 
> > Since 4.17.rc1, this driver uses REGMAP; I'll send a separate patch to
> > address this issue.
> > 
> > Cc: sta...@vger.kernel.org
> > Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR 
> > reconfiguration)
> 
> Looks like part of the problem was introduced in that patch, part well 
> predated
> it (BDU).
> 
> > Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
> 
> As you way, this needs to be a bit different to take into account
> the change to regmap.  We'll need to have that upstream before we look
> at a back port.  One element inline surprises me and needs further
> explanation.
I have sent a patch based on iio-for-4.17b [1], Lorenzo and I are still 
discussing our findings. It's not just the CTRL1 reg, but also the 
AV_CONF(0x10) reg.
which loses it's contents coming out of suspend.

[1] https://marc.info/?l=linux-iio=152534455701742=2
> 
> 
> > ---
> >  drivers/iio/humidity/hts221_core.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/iio/humidity/hts221_core.c 
> > b/drivers/iio/humidity/hts221_core.c
> > index 32524a8dc66f..fed2da64fa3b 100644
> > --- a/drivers/iio/humidity/hts221_core.c
> > +++ b/drivers/iio/humidity/hts221_core.c
> > @@ -674,11 +674,15 @@ static int __maybe_unused hts221_resume(struct device 
> > *dev)
> > struct hts221_hw *hw = iio_priv(iio_dev);
> > int err = 0;
> >  
> > -   if (hw->enabled)
> > -   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
> > -HTS221_ENABLE_MASK, true);
> 
> Why drop the enable setting?  Seems that we want to do this 'as well',
> if the device was previous enabled.
Yes, will cover this in v2.
> 
> > +   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
> > +HTS221_BDU_MASK, 1);
> > +   if (err < 0)
> > +   goto fail_err;
> >  
> > -   return err;
> > +   err = hts221_update_odr(hw, hw->odr);
> > +
> > +fail_err:
> > +   return err < 0 ? err : 0;
> >  }
> >  
> >  const struct dev_pm_ops hts221_pm_ops = {
> 
> 

signature.asc
Description: This is a digitally signed message part


Re: [PATCH] iio: humidity: hts221: Fix sensor reads after resume

2018-05-06 Thread Shrirang Bagul
On Sun, 2018-05-06 at 17:19 +0100, Jonathan Cameron wrote:
> On Mon, 30 Apr 2018 12:25:46 +0800
> Shrirang Bagul  wrote:
> 
> > CTRL1 register (ODR & BDU settings) gets reset after system comes back
> > from suspend, causing subsequent reads from the sensor to fail.
> > 
> > This patch restores the CTRL1 register after resume.
> > 
> > Based on:
> > git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git 
> > iio-fixes-for-4.14b
> > 
> > Since 4.17.rc1, this driver uses REGMAP; I'll send a separate patch to
> > address this issue.
> > 
> > Cc: sta...@vger.kernel.org
> > Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR 
> > reconfiguration)
> 
> Looks like part of the problem was introduced in that patch, part well 
> predated
> it (BDU).
> 
> > Signed-off-by: Shrirang Bagul 
> 
> As you way, this needs to be a bit different to take into account
> the change to regmap.  We'll need to have that upstream before we look
> at a back port.  One element inline surprises me and needs further
> explanation.
I have sent a patch based on iio-for-4.17b [1], Lorenzo and I are still 
discussing our findings. It's not just the CTRL1 reg, but also the 
AV_CONF(0x10) reg.
which loses it's contents coming out of suspend.

[1] https://marc.info/?l=linux-iio=152534455701742=2
> 
> 
> > ---
> >  drivers/iio/humidity/hts221_core.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/iio/humidity/hts221_core.c 
> > b/drivers/iio/humidity/hts221_core.c
> > index 32524a8dc66f..fed2da64fa3b 100644
> > --- a/drivers/iio/humidity/hts221_core.c
> > +++ b/drivers/iio/humidity/hts221_core.c
> > @@ -674,11 +674,15 @@ static int __maybe_unused hts221_resume(struct device 
> > *dev)
> > struct hts221_hw *hw = iio_priv(iio_dev);
> > int err = 0;
> >  
> > -   if (hw->enabled)
> > -   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
> > -HTS221_ENABLE_MASK, true);
> 
> Why drop the enable setting?  Seems that we want to do this 'as well',
> if the device was previous enabled.
Yes, will cover this in v2.
> 
> > +   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
> > +HTS221_BDU_MASK, 1);
> > +   if (err < 0)
> > +   goto fail_err;
> >  
> > -   return err;
> > +   err = hts221_update_odr(hw, hw->odr);
> > +
> > +fail_err:
> > +   return err < 0 ? err : 0;
> >  }
> >  
> >  const struct dev_pm_ops hts221_pm_ops = {
> 
> 

signature.asc
Description: This is a digitally signed message part


[PATCH] iio: humidity: hts221: Fix sensor reads after resume

2018-04-29 Thread Shrirang Bagul
CTRL1 register (ODR & BDU settings) gets reset after system comes back
from suspend, causing subsequent reads from the sensor to fail.

This patch restores the CTRL1 register after resume.

Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git iio-fixes-for-4.14b

Since 4.17.rc1, this driver uses REGMAP; I'll send a separate patch to
address this issue.

Cc: sta...@vger.kernel.org
Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR reconfiguration)
Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/iio/humidity/hts221_core.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/humidity/hts221_core.c 
b/drivers/iio/humidity/hts221_core.c
index 32524a8dc66f..fed2da64fa3b 100644
--- a/drivers/iio/humidity/hts221_core.c
+++ b/drivers/iio/humidity/hts221_core.c
@@ -674,11 +674,15 @@ static int __maybe_unused hts221_resume(struct device 
*dev)
struct hts221_hw *hw = iio_priv(iio_dev);
int err = 0;
 
-   if (hw->enabled)
-   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
-HTS221_ENABLE_MASK, true);
+   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
+HTS221_BDU_MASK, 1);
+   if (err < 0)
+   goto fail_err;
 
-   return err;
+   err = hts221_update_odr(hw, hw->odr);
+
+fail_err:
+   return err < 0 ? err : 0;
 }
 
 const struct dev_pm_ops hts221_pm_ops = {
-- 
2.14.1



[PATCH] iio: humidity: hts221: Fix sensor reads after resume

2018-04-29 Thread Shrirang Bagul
CTRL1 register (ODR & BDU settings) gets reset after system comes back
from suspend, causing subsequent reads from the sensor to fail.

This patch restores the CTRL1 register after resume.

Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git iio-fixes-for-4.14b

Since 4.17.rc1, this driver uses REGMAP; I'll send a separate patch to
address this issue.

Cc: sta...@vger.kernel.org
Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR reconfiguration)
Signed-off-by: Shrirang Bagul 
---
 drivers/iio/humidity/hts221_core.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/humidity/hts221_core.c 
b/drivers/iio/humidity/hts221_core.c
index 32524a8dc66f..fed2da64fa3b 100644
--- a/drivers/iio/humidity/hts221_core.c
+++ b/drivers/iio/humidity/hts221_core.c
@@ -674,11 +674,15 @@ static int __maybe_unused hts221_resume(struct device 
*dev)
struct hts221_hw *hw = iio_priv(iio_dev);
int err = 0;
 
-   if (hw->enabled)
-   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
-HTS221_ENABLE_MASK, true);
+   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
+HTS221_BDU_MASK, 1);
+   if (err < 0)
+   goto fail_err;
 
-   return err;
+   err = hts221_update_odr(hw, hw->odr);
+
+fail_err:
+   return err < 0 ? err : 0;
 }
 
 const struct dev_pm_ops hts221_pm_ops = {
-- 
2.14.1



Re: [PATCH] net: qmi_wwan: add Dell DW5818, DW5819

2017-11-20 Thread Shrirang Bagul
On Mon, 2017-11-20 at 10:41 +0100, Bjørn Mork wrote:
> Shrirang Bagul <shrirang.ba...@canonical.com> writes:
> 
> > Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
> > series modems which will by default boot with vid 0x413c and pid's
> > 0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
> > qmi_wwan on the usb interface #12.
> 
> NAK,
> 
> Interace #12 is MBIM, as shown by the device descriptors. Please provide
> those descriptors and you will see that this interface is clearly a CDC
> MBIM class interface.
> 
> Yes, I know these modems probe the control protocol so that you can make
> QMI work on an MBIM control interface by sending it a QMI request as the
> first messsage.  This is still wrong, abusing a quirky firmware
> feature.
> 
> You need to reconfigure the modem for QMI using the Sierra specific AT
> command or QMI request (tunneled in MBIM!) to properly switch it to QMI
> mode, which will appear as a vendor specific interface number 8 (and 10
> if you enable both QMI functions).
Understood. Needs more work, will resend with fixes.

- Shrirang
> 
> 
> 
> 
> 
> Bjørn

signature.asc
Description: This is a digitally signed message part


Re: [PATCH] net: qmi_wwan: add Dell DW5818, DW5819

2017-11-20 Thread Shrirang Bagul
On Mon, 2017-11-20 at 10:41 +0100, Bjørn Mork wrote:
> Shrirang Bagul  writes:
> 
> > Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
> > series modems which will by default boot with vid 0x413c and pid's
> > 0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
> > qmi_wwan on the usb interface #12.
> 
> NAK,
> 
> Interace #12 is MBIM, as shown by the device descriptors. Please provide
> those descriptors and you will see that this interface is clearly a CDC
> MBIM class interface.
> 
> Yes, I know these modems probe the control protocol so that you can make
> QMI work on an MBIM control interface by sending it a QMI request as the
> first messsage.  This is still wrong, abusing a quirky firmware
> feature.
> 
> You need to reconfigure the modem for QMI using the Sierra specific AT
> command or QMI request (tunneled in MBIM!) to properly switch it to QMI
> mode, which will appear as a vendor specific interface number 8 (and 10
> if you enable both QMI functions).
Understood. Needs more work, will resend with fixes.

- Shrirang
> 
> 
> 
> 
> 
> Bjørn

signature.asc
Description: This is a digitally signed message part


[PATCH] net: qmi_wwan: add Dell DW5818, DW5819

2017-11-20 Thread Shrirang Bagul
Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series modems which will by default boot with vid 0x413c and pid's
0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
qmi_wwan on the usb interface #12.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/net/usb/qmi_wwan.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8d4a6f7cba61..bdf1fae38af2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1234,6 +1234,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)},/* Dell Wireless 5809e Gobi(TM) 
4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)},/* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)},   /* Dell Wireless 5811e */
+   {QMI_FIXED_INTF(0x413c, 0x81cf, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d0, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d1, 12)},   /* Dell Wireless 5818 */
+   {QMI_FIXED_INTF(0x413c, 0x81d2, 12)},   /* Dell Wireless 5818 */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+ 
Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
-- 
2.14.1



[PATCH] net: qmi_wwan: add Dell DW5818, DW5819

2017-11-20 Thread Shrirang Bagul
Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series modems which will by default boot with vid 0x413c and pid's
0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
qmi_wwan on the usb interface #12.

Signed-off-by: Shrirang Bagul 
---
 drivers/net/usb/qmi_wwan.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8d4a6f7cba61..bdf1fae38af2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1234,6 +1234,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)},/* Dell Wireless 5809e Gobi(TM) 
4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)},/* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)},   /* Dell Wireless 5811e */
+   {QMI_FIXED_INTF(0x413c, 0x81cf, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d0, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d1, 12)},   /* Dell Wireless 5818 */
+   {QMI_FIXED_INTF(0x413c, 0x81d2, 12)},   /* Dell Wireless 5818 */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+ 
Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
-- 
2.14.1



Re: [PATCH] USB: serial: qcserial: add Dell DW5818, DW5819

2017-10-04 Thread Shrirang Bagul
On Tue, 2017-10-03 at 15:37 +0200, Johan Hovold wrote:
> On Fri, Sep 29, 2017 at 12:39:51PM +0800, Shrirang Bagul wrote:
> > Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
> > series which will by default boot with vid 0x413c and pid's 0x81cf,
> > 0x81d0, 0x81d1,0x81d2.
> > 
> > Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
> 
> Now applied.
Thank you.
> 
> Don't you want to add these to qmi_wwan as well?
I haven't tested these devices with qmi_wwan. Perhaps a separate patch once it's
verified.
> 
> > ---
> >  drivers/usb/serial/qcserial.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> > index ebc0beea69d6..eb9928963a53 100644
> > --- a/drivers/usb/serial/qcserial.c
> > +++ b/drivers/usb/serial/qcserial.c
> > @@ -174,6 +174,10 @@ static const struct usb_device_id id_table[] = {
> >     {DEVICE_SWI(0x413c, 0x81b3)},   /* Dell Wireless 5809e Gobi(TM) 4G
> > LTE Mobile Broadband Card (rev3) */
> >     {DEVICE_SWI(0x413c, 0x81b5)},   /* Dell Wireless 5811e QDL */
> >     {DEVICE_SWI(0x413c, 0x81b6)},   /* Dell Wireless 5811e QDL */
> > +   {DEVICE_SWI(0x413c, 0x81cf)},   /* Dell Wireless 5819 */
> > +   {DEVICE_SWI(0x413c, 0x81d0)},   /* Dell Wireless 5819 */
> > +   {DEVICE_SWI(0x413c, 0x81d1)},   /* Dell Wireless 5818 */
> > +   {DEVICE_SWI(0x413c, 0x81d2)},   /* Dell Wireless 5818 */
> >  
> >     /* Huawei devices */
> >     {DEVICE_HWI(0x03f0, 0x581d)},   /* HP lt4112 LTE/HSPA+ Gobi 4G
> > Modem (Huawei me906e) */
> 
> Thanks,
> Johan


Re: [PATCH] USB: serial: qcserial: add Dell DW5818, DW5819

2017-10-04 Thread Shrirang Bagul
On Tue, 2017-10-03 at 15:37 +0200, Johan Hovold wrote:
> On Fri, Sep 29, 2017 at 12:39:51PM +0800, Shrirang Bagul wrote:
> > Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
> > series which will by default boot with vid 0x413c and pid's 0x81cf,
> > 0x81d0, 0x81d1,0x81d2.
> > 
> > Signed-off-by: Shrirang Bagul 
> 
> Now applied.
Thank you.
> 
> Don't you want to add these to qmi_wwan as well?
I haven't tested these devices with qmi_wwan. Perhaps a separate patch once it's
verified.
> 
> > ---
> >  drivers/usb/serial/qcserial.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> > index ebc0beea69d6..eb9928963a53 100644
> > --- a/drivers/usb/serial/qcserial.c
> > +++ b/drivers/usb/serial/qcserial.c
> > @@ -174,6 +174,10 @@ static const struct usb_device_id id_table[] = {
> >     {DEVICE_SWI(0x413c, 0x81b3)},   /* Dell Wireless 5809e Gobi(TM) 4G
> > LTE Mobile Broadband Card (rev3) */
> >     {DEVICE_SWI(0x413c, 0x81b5)},   /* Dell Wireless 5811e QDL */
> >     {DEVICE_SWI(0x413c, 0x81b6)},   /* Dell Wireless 5811e QDL */
> > +   {DEVICE_SWI(0x413c, 0x81cf)},   /* Dell Wireless 5819 */
> > +   {DEVICE_SWI(0x413c, 0x81d0)},   /* Dell Wireless 5819 */
> > +   {DEVICE_SWI(0x413c, 0x81d1)},   /* Dell Wireless 5818 */
> > +   {DEVICE_SWI(0x413c, 0x81d2)},   /* Dell Wireless 5818 */
> >  
> >     /* Huawei devices */
> >     {DEVICE_HWI(0x03f0, 0x581d)},   /* HP lt4112 LTE/HSPA+ Gobi 4G
> > Modem (Huawei me906e) */
> 
> Thanks,
> Johan


[PATCH] USB: serial: qcserial: add Dell DW5818, DW5819

2017-09-28 Thread Shrirang Bagul
Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series which will by default boot with vid 0x413c and pid's 0x81cf,
0x81d0, 0x81d1,0x81d2.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/usb/serial/qcserial.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index ebc0beea69d6..eb9928963a53 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -174,6 +174,10 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x413c, 0x81b3)},   /* Dell Wireless 5809e Gobi(TM) 4G LTE 
Mobile Broadband Card (rev3) */
{DEVICE_SWI(0x413c, 0x81b5)},   /* Dell Wireless 5811e QDL */
{DEVICE_SWI(0x413c, 0x81b6)},   /* Dell Wireless 5811e QDL */
+   {DEVICE_SWI(0x413c, 0x81cf)},   /* Dell Wireless 5819 */
+   {DEVICE_SWI(0x413c, 0x81d0)},   /* Dell Wireless 5819 */
+   {DEVICE_SWI(0x413c, 0x81d1)},   /* Dell Wireless 5818 */
+   {DEVICE_SWI(0x413c, 0x81d2)},   /* Dell Wireless 5818 */
 
/* Huawei devices */
{DEVICE_HWI(0x03f0, 0x581d)},   /* HP lt4112 LTE/HSPA+ Gobi 4G Modem 
(Huawei me906e) */
-- 
2.11.0



[PATCH] USB: serial: qcserial: add Dell DW5818, DW5819

2017-09-28 Thread Shrirang Bagul
Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series which will by default boot with vid 0x413c and pid's 0x81cf,
0x81d0, 0x81d1,0x81d2.

Signed-off-by: Shrirang Bagul 
---
 drivers/usb/serial/qcserial.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index ebc0beea69d6..eb9928963a53 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -174,6 +174,10 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x413c, 0x81b3)},   /* Dell Wireless 5809e Gobi(TM) 4G LTE 
Mobile Broadband Card (rev3) */
{DEVICE_SWI(0x413c, 0x81b5)},   /* Dell Wireless 5811e QDL */
{DEVICE_SWI(0x413c, 0x81b6)},   /* Dell Wireless 5811e QDL */
+   {DEVICE_SWI(0x413c, 0x81cf)},   /* Dell Wireless 5819 */
+   {DEVICE_SWI(0x413c, 0x81d0)},   /* Dell Wireless 5819 */
+   {DEVICE_SWI(0x413c, 0x81d1)},   /* Dell Wireless 5818 */
+   {DEVICE_SWI(0x413c, 0x81d2)},   /* Dell Wireless 5818 */
 
/* Huawei devices */
{DEVICE_HWI(0x03f0, 0x581d)},   /* HP lt4112 LTE/HSPA+ Gobi 4G Modem 
(Huawei me906e) */
-- 
2.11.0



[PATCH] HID: multitouch: Support ALPS PTP stick with pid 0x120A

2017-08-10 Thread Shrirang Bagul
This patch adds ALPS PTP sticks with pid/device id 0x120A to the list of
devices supported by hid-multitouch.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/hid/hid-ids.h| 1 +
 drivers/hid/hid-multitouch.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index b397a14ab970..97197cf2362f 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -75,6 +75,7 @@
 
 #define USB_VENDOR_ID_ALPS_JP  0x044E
 #define HID_DEVICE_ID_ALPS_U1_DUAL 0x120B
+#define HID_DEVICE_ID_ALPS_U1_PTP_20x120A
 #define HID_DEVICE_ID_ALPS_U1_DUAL_PTP 0x121F
 #define HID_DEVICE_ID_ALPS_U1_DUAL_3BTN_PTP0x1220
 
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 440b999304a5..f309871bad15 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1418,6 +1418,10 @@ static const struct hid_device_id mt_devices[] = {
HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
USB_VENDOR_ID_ALPS_JP,
HID_DEVICE_ID_ALPS_U1_DUAL_3BTN_PTP) },
+   { .driver_data = MT_CLS_WIN_8_DUAL,
+   HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+   USB_VENDOR_ID_ALPS_JP,
+   HID_DEVICE_ID_ALPS_U1_PTP_2) },
 
/* Anton devices */
{ .driver_data = MT_CLS_EXPORT_ALL_INPUTS,
-- 
2.11.0



[PATCH] HID: multitouch: Support ALPS PTP stick with pid 0x120A

2017-08-10 Thread Shrirang Bagul
This patch adds ALPS PTP sticks with pid/device id 0x120A to the list of
devices supported by hid-multitouch.

Signed-off-by: Shrirang Bagul 
---
 drivers/hid/hid-ids.h| 1 +
 drivers/hid/hid-multitouch.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index b397a14ab970..97197cf2362f 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -75,6 +75,7 @@
 
 #define USB_VENDOR_ID_ALPS_JP  0x044E
 #define HID_DEVICE_ID_ALPS_U1_DUAL 0x120B
+#define HID_DEVICE_ID_ALPS_U1_PTP_20x120A
 #define HID_DEVICE_ID_ALPS_U1_DUAL_PTP 0x121F
 #define HID_DEVICE_ID_ALPS_U1_DUAL_3BTN_PTP0x1220
 
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 440b999304a5..f309871bad15 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1418,6 +1418,10 @@ static const struct hid_device_id mt_devices[] = {
HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
USB_VENDOR_ID_ALPS_JP,
HID_DEVICE_ID_ALPS_U1_DUAL_3BTN_PTP) },
+   { .driver_data = MT_CLS_WIN_8_DUAL,
+   HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+   USB_VENDOR_ID_ALPS_JP,
+   HID_DEVICE_ID_ALPS_U1_PTP_2) },
 
/* Anton devices */
{ .driver_data = MT_CLS_EXPORT_ALL_INPUTS,
-- 
2.11.0



Re: [PATCH] iio: st_pressure: st_accel: Initialise sensor platform data properly

2017-04-27 Thread Shrirang Bagul
On Wed, 2017-04-26 at 06:37 +0100, Jonathan Cameron wrote:
> On 19/04/17 15:05, Shrirang Bagul wrote:
> > This patch fixes the sensor platform data initialisation for st_pressure
> > and st_accel device drivers. Without this patch, the driver fails to
> > register the sensors when the user removes and re-loads the driver.
> > 
> > 1. Unload the kernel modules for st_pressure
> > $ sudo rmmod st_pressure_i2c
> > $ sudo rmmod st_pressure
> > 
> > 2. Re-load the driver
> > $ sudo insmod st_pressure
> > $ sudo insmod st_pressure_i2c
> > --- OR ---
> > $ sudo modprobe st_pressure_i2c
> > 
> > dmesg errors:
> > 
> > [ 160.935707] iio iio:device2: DRDY on pdata not valid.
> > [ 160.941505] st-press-i2c: probe of i2c-SMO9210:00 failed with error -22
> > 
> > The driver fails to register the pressure sensor device. Devices
> > supported by st_accel driver also suffer from the same bug.
> > 
> > Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
> 
> Unless I am missing something, the severity of this bug is fairly minor
> so whilst I'm pleased to have it fixed, I'm not intending to mark this
> for stable.
> 
> If anyone has a cunning way of exploiting it then let me know!
Stress testing st_pressure_i2c, st_pressure module load/unload does cause the 
kernel
to panic.

Apr 27 18:11:21 caracalla kernel: [ 8417.756968] BUG: unable to handle kernel 
paging
request at c0377c48
Apr 27 18:11:21 caracalla kernel: [ 8417.764869] IP: []
st_sensors_init_sensor+0x26/0x1f0 [st_sensors]
Apr 27 18:11:21 caracalla kernel: [ 8417.773550] PGD 2e0d067 PUD 2e0f067 PMD 
3792b067
PTE 0
Apr 27 18:11:21 caracalla kernel: [ 8417.779382] Oops:  [#1] SMP
Apr 27 18:11:21 caracalla kernel: [ 8417.783045] Modules linked in:
st_pressure_i2c(+) st_pressure hts221_i2c msr cmac algif_hash algif_skcipher 
af_alg
hci_vhci rfcomm bnep arc4 iTCO_wdt iTCO_vendor_support snd_soc_sst_bytcr_rt5660
dell_wmi sparse_keymap ven_rsi_sdio ven_rsi_91x intel_soc_dts_iosf bluetooth
intel_powerclamp coretemp kvm_intel kvm dcdbas mac80211 irqbypass 
punit_atom_debug
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 
cfg80211 lrw
gf128mul glue_helper ablk_helper input_leds cryptd psmouse serio_raw cdc_mbim 
cdc_wdm
cdc_ncm uas r8169 usbnet cdc_acm lpc_ich mii mei_txe mei snd_intel_sst_acpi 
shpchp
snd_intel_sst_core snd_soc_rt5660 snd_soc_sst_mfld_platform snd_soc_rl6231
snd_soc_core 8250_fintek fjes st_accel_i2c st_accel st_sensors_i2c hts221 
i2c_hid
st_sensors snd_compress ad5593r ac97_bus hid industrialio_triggered_buffer 
kfifo_buf
ad5592r_base industrialio snd_pcm_dmaengine snd_pcm tpm_crb snd_timer dw_dmac 
snd
dw_dmac_core soundcore rfkill_gpio mac_hid spi_pxa2xx_platform
i2c_designware_platform i2c_designware_core pwm_lpss_platform snd_soc_sst_acpi
8250_dw pwm_lpss iptable_filter ip_tables ip6table_filter ip6_tables x_tables 
autofs4
sdhci_pci virtio_scsi ahci libahci mmc_block i915 i2c_algo_bit drm_kms_helper
syscopyarea sysfillrect sysimgblt fb_sys_fops usb_storage drm wmi video 
sdhci_acpi
sdhci [last unloaded: st_pressure]
Apr 27 18:11:21 caracalla kernel: [ 8417.917926] CPU: 0 PID: 15523 Comm: 
modprobe Not
tainted 4.4.0-77-generic #98-Ubuntu
Apr 27 18:11:21 caracalla kernel: [ 8417.926686] Hardware name: Dell Inc. Edge
Gateway 3003/ , BIOS 00.00.28 03/23/2017
Apr 27 18:11:21 caracalla kernel: [ 8417.935739] task: 88007521a640 ti:
88007639c000 task.ti: 88007639c000
Apr 27 18:11:21 caracalla kernel: [ 8417.944202] RIP: 0010:[]
[] st_sensors_init_sensor+0x26/0x1f0 [st_sensors]
Apr 27 18:11:21 caracalla kernel: [ 8417.955627] RSP: 0018:88007639fac8 
EFLAGS:
00010206
Apr 27 18:11:21 caracalla kernel: [ 8417.961632] RAX: c0328640 RBX:
880076832800 RCX: 0003
Apr 27 18:11:21 caracalla kernel: [ 8417.969702] RDX: 8800371c9820 RSI:
c0377c48 RDI: 880076832800
Apr 27 18:11:21 caracalla kernel: [ 8417.92] RBP: 88007639fad0 R08:
88007639c000 R09: 
Apr 27 18:11:21 caracalla kernel: [ 8417.985841] R10: 00b6 R11:
 R12: 
Apr 27 18:11:21 caracalla kernel: [ 8417.993911] R13: 0003 R14:
880076832cc0 R15: c03730a0
Apr 27 18:11:21 caracalla kernel: [ 8418.001982] FS: 7f71faa83700()
GS:880070a0() knlGS:
Apr 27 18:11:21 caracalla kernel: [ 8418.011133] CS: 0010 DS:  ES:  CR0:
80050033
Apr 27 18:11:21 caracalla kernel: [ 8418.017629] CR2: c0377c48 CR3:
74d7d000 CR4: 001006f0
Apr 27 18:11:21 caracalla kernel: [ 8418.025698] Stack:
Apr 27 18:11:21 caracalla kernel: [ 8418.027967] 880076832800 
88007639faf8
c03270ea 880076832800
Apr 27 18:11:21 caracalla kernel: [ 8418.036363] 8800371c9800 
8800371c9820
88007639fb30 ff

Re: [PATCH] iio: st_pressure: st_accel: Initialise sensor platform data properly

2017-04-27 Thread Shrirang Bagul
On Wed, 2017-04-26 at 06:37 +0100, Jonathan Cameron wrote:
> On 19/04/17 15:05, Shrirang Bagul wrote:
> > This patch fixes the sensor platform data initialisation for st_pressure
> > and st_accel device drivers. Without this patch, the driver fails to
> > register the sensors when the user removes and re-loads the driver.
> > 
> > 1. Unload the kernel modules for st_pressure
> > $ sudo rmmod st_pressure_i2c
> > $ sudo rmmod st_pressure
> > 
> > 2. Re-load the driver
> > $ sudo insmod st_pressure
> > $ sudo insmod st_pressure_i2c
> > --- OR ---
> > $ sudo modprobe st_pressure_i2c
> > 
> > dmesg errors:
> > 
> > [ 160.935707] iio iio:device2: DRDY on pdata not valid.
> > [ 160.941505] st-press-i2c: probe of i2c-SMO9210:00 failed with error -22
> > 
> > The driver fails to register the pressure sensor device. Devices
> > supported by st_accel driver also suffer from the same bug.
> > 
> > Signed-off-by: Shrirang Bagul 
> 
> Unless I am missing something, the severity of this bug is fairly minor
> so whilst I'm pleased to have it fixed, I'm not intending to mark this
> for stable.
> 
> If anyone has a cunning way of exploiting it then let me know!
Stress testing st_pressure_i2c, st_pressure module load/unload does cause the 
kernel
to panic.

Apr 27 18:11:21 caracalla kernel: [ 8417.756968] BUG: unable to handle kernel 
paging
request at c0377c48
Apr 27 18:11:21 caracalla kernel: [ 8417.764869] IP: []
st_sensors_init_sensor+0x26/0x1f0 [st_sensors]
Apr 27 18:11:21 caracalla kernel: [ 8417.773550] PGD 2e0d067 PUD 2e0f067 PMD 
3792b067
PTE 0
Apr 27 18:11:21 caracalla kernel: [ 8417.779382] Oops:  [#1] SMP
Apr 27 18:11:21 caracalla kernel: [ 8417.783045] Modules linked in:
st_pressure_i2c(+) st_pressure hts221_i2c msr cmac algif_hash algif_skcipher 
af_alg
hci_vhci rfcomm bnep arc4 iTCO_wdt iTCO_vendor_support snd_soc_sst_bytcr_rt5660
dell_wmi sparse_keymap ven_rsi_sdio ven_rsi_91x intel_soc_dts_iosf bluetooth
intel_powerclamp coretemp kvm_intel kvm dcdbas mac80211 irqbypass 
punit_atom_debug
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 
cfg80211 lrw
gf128mul glue_helper ablk_helper input_leds cryptd psmouse serio_raw cdc_mbim 
cdc_wdm
cdc_ncm uas r8169 usbnet cdc_acm lpc_ich mii mei_txe mei snd_intel_sst_acpi 
shpchp
snd_intel_sst_core snd_soc_rt5660 snd_soc_sst_mfld_platform snd_soc_rl6231
snd_soc_core 8250_fintek fjes st_accel_i2c st_accel st_sensors_i2c hts221 
i2c_hid
st_sensors snd_compress ad5593r ac97_bus hid industrialio_triggered_buffer 
kfifo_buf
ad5592r_base industrialio snd_pcm_dmaengine snd_pcm tpm_crb snd_timer dw_dmac 
snd
dw_dmac_core soundcore rfkill_gpio mac_hid spi_pxa2xx_platform
i2c_designware_platform i2c_designware_core pwm_lpss_platform snd_soc_sst_acpi
8250_dw pwm_lpss iptable_filter ip_tables ip6table_filter ip6_tables x_tables 
autofs4
sdhci_pci virtio_scsi ahci libahci mmc_block i915 i2c_algo_bit drm_kms_helper
syscopyarea sysfillrect sysimgblt fb_sys_fops usb_storage drm wmi video 
sdhci_acpi
sdhci [last unloaded: st_pressure]
Apr 27 18:11:21 caracalla kernel: [ 8417.917926] CPU: 0 PID: 15523 Comm: 
modprobe Not
tainted 4.4.0-77-generic #98-Ubuntu
Apr 27 18:11:21 caracalla kernel: [ 8417.926686] Hardware name: Dell Inc. Edge
Gateway 3003/ , BIOS 00.00.28 03/23/2017
Apr 27 18:11:21 caracalla kernel: [ 8417.935739] task: 88007521a640 ti:
88007639c000 task.ti: 88007639c000
Apr 27 18:11:21 caracalla kernel: [ 8417.944202] RIP: 0010:[]
[] st_sensors_init_sensor+0x26/0x1f0 [st_sensors]
Apr 27 18:11:21 caracalla kernel: [ 8417.955627] RSP: 0018:88007639fac8 
EFLAGS:
00010206
Apr 27 18:11:21 caracalla kernel: [ 8417.961632] RAX: c0328640 RBX:
880076832800 RCX: 0003
Apr 27 18:11:21 caracalla kernel: [ 8417.969702] RDX: 8800371c9820 RSI:
c0377c48 RDI: 880076832800
Apr 27 18:11:21 caracalla kernel: [ 8417.92] RBP: 88007639fad0 R08:
88007639c000 R09: 
Apr 27 18:11:21 caracalla kernel: [ 8417.985841] R10: 00b6 R11:
 R12: 
Apr 27 18:11:21 caracalla kernel: [ 8417.993911] R13: 0003 R14:
880076832cc0 R15: c03730a0
Apr 27 18:11:21 caracalla kernel: [ 8418.001982] FS: 7f71faa83700()
GS:880070a0() knlGS:
Apr 27 18:11:21 caracalla kernel: [ 8418.011133] CS: 0010 DS:  ES:  CR0:
80050033
Apr 27 18:11:21 caracalla kernel: [ 8418.017629] CR2: c0377c48 CR3:
74d7d000 CR4: 001006f0
Apr 27 18:11:21 caracalla kernel: [ 8418.025698] Stack:
Apr 27 18:11:21 caracalla kernel: [ 8418.027967] 880076832800 
88007639faf8
c03270ea 880076832800
Apr 27 18:11:21 caracalla kernel: [ 8418.036363] 8800371c9800 
8800371c9820
88007639fb30 c037207d
Apr 27 18:11:21 caracal

[PATCH] iio: st_pressure: st_accel: Initialise sensor platform data properly

2017-04-19 Thread Shrirang Bagul
This patch fixes the sensor platform data initialisation for st_pressure
and st_accel device drivers. Without this patch, the driver fails to
register the sensors when the user removes and re-loads the driver.

1. Unload the kernel modules for st_pressure
$ sudo rmmod st_pressure_i2c
$ sudo rmmod st_pressure

2. Re-load the driver
$ sudo insmod st_pressure
$ sudo insmod st_pressure_i2c
--- OR ---
$ sudo modprobe st_pressure_i2c

dmesg errors:

[ 160.935707] iio iio:device2: DRDY on pdata not valid.
[ 160.941505] st-press-i2c: probe of i2c-SMO9210:00 failed with error -22

The driver fails to register the pressure sensor device. Devices
supported by st_accel driver also suffer from the same bug.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/iio/accel/st_accel_core.c   | 7 ---
 drivers/iio/pressure/st_pressure_core.c | 8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/iio/accel/st_accel_core.c 
b/drivers/iio/accel/st_accel_core.c
index 784670e2736b..07d1489cd457 100644
--- a/drivers/iio/accel/st_accel_core.c
+++ b/drivers/iio/accel/st_accel_core.c
@@ -710,6 +710,8 @@ static const struct iio_trigger_ops st_accel_trigger_ops = {
 int st_accel_common_probe(struct iio_dev *indio_dev)
 {
struct st_sensor_data *adata = iio_priv(indio_dev);
+   struct st_sensors_platform_data *pdata =
+   (struct st_sensors_platform_data *)adata->dev->platform_data;
int irq = adata->get_irq_data_ready(indio_dev);
int err;
 
@@ -736,9 +738,8 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
>sensor_settings->fs.fs_avl[0];
adata->odr = adata->sensor_settings->odr.odr_avl[0].hz;
 
-   if (!adata->dev->platform_data)
-   adata->dev->platform_data =
-   (struct st_sensors_platform_data *)_accel_pdata;
+   if (!pdata)
+   pdata = (struct st_sensors_platform_data *)_accel_pdata;
 
err = st_sensors_init_sensor(indio_dev, adata->dev->platform_data);
if (err < 0)
diff --git a/drivers/iio/pressure/st_pressure_core.c 
b/drivers/iio/pressure/st_pressure_core.c
index 5f268082..0d8d5665769a 100644
--- a/drivers/iio/pressure/st_pressure_core.c
+++ b/drivers/iio/pressure/st_pressure_core.c
@@ -567,6 +567,8 @@ static const struct iio_trigger_ops st_press_trigger_ops = {
 int st_press_common_probe(struct iio_dev *indio_dev)
 {
struct st_sensor_data *press_data = iio_priv(indio_dev);
+   struct st_sensors_platform_data *pdata =
+   (struct st_sensors_platform_data 
*)press_data->dev->platform_data;
int irq = press_data->get_irq_data_ready(indio_dev);
int err;
 
@@ -602,10 +604,8 @@ int st_press_common_probe(struct iio_dev *indio_dev)
press_data->odr = press_data->sensor_settings->odr.odr_avl[0].hz;
 
/* Some devices don't support a data ready pin. */
-   if (!press_data->dev->platform_data &&
-   press_data->sensor_settings->drdy_irq.addr)
-   press_data->dev->platform_data =
-   (struct st_sensors_platform_data *)_press_pdata;
+   if (!pdata && press_data->sensor_settings->drdy_irq.addr)
+   pdata = (struct st_sensors_platform_data *)_press_pdata;
 
err = st_sensors_init_sensor(indio_dev, press_data->dev->platform_data);
if (err < 0)
-- 
2.11.0



[PATCH] iio: st_pressure: st_accel: Initialise sensor platform data properly

2017-04-19 Thread Shrirang Bagul
This patch fixes the sensor platform data initialisation for st_pressure
and st_accel device drivers. Without this patch, the driver fails to
register the sensors when the user removes and re-loads the driver.

1. Unload the kernel modules for st_pressure
$ sudo rmmod st_pressure_i2c
$ sudo rmmod st_pressure

2. Re-load the driver
$ sudo insmod st_pressure
$ sudo insmod st_pressure_i2c
--- OR ---
$ sudo modprobe st_pressure_i2c

dmesg errors:

[ 160.935707] iio iio:device2: DRDY on pdata not valid.
[ 160.941505] st-press-i2c: probe of i2c-SMO9210:00 failed with error -22

The driver fails to register the pressure sensor device. Devices
supported by st_accel driver also suffer from the same bug.

Signed-off-by: Shrirang Bagul 
---
 drivers/iio/accel/st_accel_core.c   | 7 ---
 drivers/iio/pressure/st_pressure_core.c | 8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/iio/accel/st_accel_core.c 
b/drivers/iio/accel/st_accel_core.c
index 784670e2736b..07d1489cd457 100644
--- a/drivers/iio/accel/st_accel_core.c
+++ b/drivers/iio/accel/st_accel_core.c
@@ -710,6 +710,8 @@ static const struct iio_trigger_ops st_accel_trigger_ops = {
 int st_accel_common_probe(struct iio_dev *indio_dev)
 {
struct st_sensor_data *adata = iio_priv(indio_dev);
+   struct st_sensors_platform_data *pdata =
+   (struct st_sensors_platform_data *)adata->dev->platform_data;
int irq = adata->get_irq_data_ready(indio_dev);
int err;
 
@@ -736,9 +738,8 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
>sensor_settings->fs.fs_avl[0];
adata->odr = adata->sensor_settings->odr.odr_avl[0].hz;
 
-   if (!adata->dev->platform_data)
-   adata->dev->platform_data =
-   (struct st_sensors_platform_data *)_accel_pdata;
+   if (!pdata)
+   pdata = (struct st_sensors_platform_data *)_accel_pdata;
 
err = st_sensors_init_sensor(indio_dev, adata->dev->platform_data);
if (err < 0)
diff --git a/drivers/iio/pressure/st_pressure_core.c 
b/drivers/iio/pressure/st_pressure_core.c
index 5f268082..0d8d5665769a 100644
--- a/drivers/iio/pressure/st_pressure_core.c
+++ b/drivers/iio/pressure/st_pressure_core.c
@@ -567,6 +567,8 @@ static const struct iio_trigger_ops st_press_trigger_ops = {
 int st_press_common_probe(struct iio_dev *indio_dev)
 {
struct st_sensor_data *press_data = iio_priv(indio_dev);
+   struct st_sensors_platform_data *pdata =
+   (struct st_sensors_platform_data 
*)press_data->dev->platform_data;
int irq = press_data->get_irq_data_ready(indio_dev);
int err;
 
@@ -602,10 +604,8 @@ int st_press_common_probe(struct iio_dev *indio_dev)
press_data->odr = press_data->sensor_settings->odr.odr_avl[0].hz;
 
/* Some devices don't support a data ready pin. */
-   if (!press_data->dev->platform_data &&
-   press_data->sensor_settings->drdy_irq.addr)
-   press_data->dev->platform_data =
-   (struct st_sensors_platform_data *)_press_pdata;
+   if (!pdata && press_data->sensor_settings->drdy_irq.addr)
+   pdata = (struct st_sensors_platform_data *)_press_pdata;
 
err = st_sensors_init_sensor(indio_dev, press_data->dev->platform_data);
if (err < 0)
-- 
2.11.0



[RESEND PATCH] iio: st_pressure: initialize lps22hb bootime

2017-03-30 Thread Shrirang Bagul
This patch initializes the bootime in struct st_sensor_settings for
lps22hb sensor. Without this, sensor channels read from sysfs always
report stale values.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/iio/pressure/st_pressure_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/pressure/st_pressure_core.c 
b/drivers/iio/pressure/st_pressure_core.c
index 5f26808..fd0edca 100644
--- a/drivers/iio/pressure/st_pressure_core.c
+++ b/drivers/iio/pressure/st_pressure_core.c
@@ -457,6 +457,7 @@ static const struct st_sensor_settings 
st_press_sensors_settings[] = {
.addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR,
},
.multi_read_bit = true,
+   .bootime = 2,
},
 };
 
-- 
2.9.3



[RESEND PATCH] iio: st_pressure: initialize lps22hb bootime

2017-03-30 Thread Shrirang Bagul
This patch initializes the bootime in struct st_sensor_settings for
lps22hb sensor. Without this, sensor channels read from sysfs always
report stale values.

Signed-off-by: Shrirang Bagul 
---
 drivers/iio/pressure/st_pressure_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/pressure/st_pressure_core.c 
b/drivers/iio/pressure/st_pressure_core.c
index 5f26808..fd0edca 100644
--- a/drivers/iio/pressure/st_pressure_core.c
+++ b/drivers/iio/pressure/st_pressure_core.c
@@ -457,6 +457,7 @@ static const struct st_sensor_settings 
st_press_sensors_settings[] = {
.addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR,
},
.multi_read_bit = true,
+   .bootime = 2,
},
 };
 
-- 
2.9.3



iio: st_pressure: initialize lps22hb bootime

2017-03-30 Thread Shrirang Bagul
This patch initializes the bootime in struct st_sensor_settings for
lps22hb sensor. Without this, sensor channels read from sysfs always
report stale values.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/iio/pressure/st_pressure_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/pressure/st_pressure_core.c 
b/drivers/iio/pressure/st_pressure_core.c
index 5f26808..fd0edca 100644
--- a/drivers/iio/pressure/st_pressure_core.c
+++ b/drivers/iio/pressure/st_pressure_core.c
@@ -457,6 +457,7 @@ static const struct st_sensor_settings 
st_press_sensors_settings[] = {
.addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR,
},
.multi_read_bit = true,
+   .bootime = 2,
},
 };
 
-- 
2.9.3



iio: st_pressure: initialize lps22hb bootime

2017-03-30 Thread Shrirang Bagul
This patch initializes the bootime in struct st_sensor_settings for
lps22hb sensor. Without this, sensor channels read from sysfs always
report stale values.

Signed-off-by: Shrirang Bagul 
---
 drivers/iio/pressure/st_pressure_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/pressure/st_pressure_core.c 
b/drivers/iio/pressure/st_pressure_core.c
index 5f26808..fd0edca 100644
--- a/drivers/iio/pressure/st_pressure_core.c
+++ b/drivers/iio/pressure/st_pressure_core.c
@@ -457,6 +457,7 @@ static const struct st_sensor_settings 
st_press_sensors_settings[] = {
.addr_stat_drdy = ST_SENSORS_DEFAULT_STAT_ADDR,
},
.multi_read_bit = true,
+   .bootime = 2,
},
 };
 
-- 
2.9.3



Re: [alsa-devel] [PATCH v2 3/4] ASoC: Intel: Support rt5660 codec for Baytrail

2017-01-15 Thread Shrirang Bagul
On Thu, 2017-01-12 at 08:40 -0600, Pierre-Louis Bossart wrote:
> On 1/12/17 6:01 AM, Shrirang Bagul wrote:
> > rt5660 and rt5640 are similar codecs so reuse the bytcr_rt5640 driver.
> > RT5660 codec is used on Dell Edge IoT Gateways with ACPI ID 10EC3277.
> > These devices sport only Line-In and Line-Out jacks.
> 
> While it would be nice to avoid copy/pasting everytime we add a new 
> codec and refactor the code, I am not comfortable with a series of 
> changes below.
> Also if we do this refactoring then we might as well do it for rt5651 
> which is similar and only relies on I2S. other machine drivers enable 
> TDM mode when possible.
> And last this change has a lot of impact on how we deal with UCM files. 
> The name of the card should reflect which codec is used, and the quirks 
> be added to the long name. If you lump everything with a single name 
> then you will make it really hard for userspace to figure out which 
> controls need to be set.
> 
> So nice idea but too early to merge. NAK.
Thank you for the review, will address these comments in the next version. When
you it be appropriate to re-submit? Are we waiting for any patches which are
queued to be merged soon?
> 
> > 
> > Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
> > ---
> >  sound/soc/intel/Kconfig   |  11 +--
> >  sound/soc/intel/atom/sst/sst_acpi.c   |   2 +
> >  sound/soc/intel/boards/bytcr_rt5640.c | 156 ++-
> > ---
> >  3 files changed, 147 insertions(+), 22 deletions(-)
> > 
> > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> > index fd5d1e0..0b43b6a 100644
> > --- a/sound/soc/intel/Kconfig
> > +++ b/sound/soc/intel/Kconfig
> > @@ -147,17 +147,18 @@ config SND_SOC_INTEL_BROADWELL_MACH
> >       If unsure select "N".
> > 
> >  config SND_SOC_INTEL_BYTCR_RT5640_MACH
> > -tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with
> > RT5640 codec"
> > +   tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with
> > RT5640/5660 codec"
> >     depends on X86 && I2C && ACPI
> >     select SND_SOC_RT5640
> > +   select SND_SOC_RT5660
> >     select SND_SST_MFLD_PLATFORM
> >     select SND_SST_IPC_ACPI
> >     select SND_SOC_INTEL_SST_MATCH if ACPI
> >     help
> > -  This adds support for ASoC machine driver for Intel(R) Baytrail
> > and Baytrail-CR
> > -  platforms with RT5640 audio codec.
> > -  Say Y if you have such a device.
> > -  If unsure select "N".
> > +     This adds support for ASoC machine driver for Intel(R) Baytrail
> > and Baytrail-CR
> > +     platforms with RT5640, RT5460 audio codec.
> > +     Say Y if you have such a device.
> > +     If unsure select "N".
> > 
> >  config SND_SOC_INTEL_BYTCR_RT5651_MACH
> >  tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with
> > RT5651 codec"
> > diff --git a/sound/soc/intel/atom/sst/sst_acpi.c
> > b/sound/soc/intel/atom/sst/sst_acpi.c
> > index f4d92bb..d401457f 100644
> > --- a/sound/soc/intel/atom/sst/sst_acpi.c
> > +++ b/sound/soc/intel/atom/sst/sst_acpi.c
> > @@ -441,6 +441,8 @@ static struct sst_acpi_mach sst_acpi_bytcr[] = {
> >     _rvp_platform_data },
> >     {"10EC5642", "bytcr_rt5640", "intel/fw_sst_0f28.bin",
> > "bytcr_rt5640", NULL,
> >     _rvp_platform_data },
> > +   {"10EC3277", "bytcr_rt5640", "intel/fw_sst_0f28.bin",
> > "bytcr_rt5640", NULL,
> > +   _rvp_platform_data },
> 
> so right there you add an HID in the platform driver and you need the 
> same in the platform driver to determine which codec type this is...
> 
> >     {"INTCCFFD", "bytcr_rt5640", "intel/fw_sst_0f28.bin",
> > "bytcr_rt5640", NULL,
> >     _rvp_platform_data },
> >     {"10EC5651", "bytcr_rt5651", "intel/fw_sst_0f28.bin",
> > "bytcr_rt5651", NULL,
> > diff --git a/sound/soc/intel/boards/bytcr_rt5640.c
> > b/sound/soc/intel/boards/bytcr_rt5640.c
> > index f6fd397..e8c9a01 100644
> > --- a/sound/soc/intel/boards/bytcr_rt5640.c
> > +++ b/sound/soc/intel/boards/bytcr_rt5640.c
> > @@ -32,11 +32,17 @@
> >  #include 
> >  #include 
> >  #include "../../cod

Re: [alsa-devel] [PATCH v2 3/4] ASoC: Intel: Support rt5660 codec for Baytrail

2017-01-15 Thread Shrirang Bagul
On Thu, 2017-01-12 at 08:40 -0600, Pierre-Louis Bossart wrote:
> On 1/12/17 6:01 AM, Shrirang Bagul wrote:
> > rt5660 and rt5640 are similar codecs so reuse the bytcr_rt5640 driver.
> > RT5660 codec is used on Dell Edge IoT Gateways with ACPI ID 10EC3277.
> > These devices sport only Line-In and Line-Out jacks.
> 
> While it would be nice to avoid copy/pasting everytime we add a new 
> codec and refactor the code, I am not comfortable with a series of 
> changes below.
> Also if we do this refactoring then we might as well do it for rt5651 
> which is similar and only relies on I2S. other machine drivers enable 
> TDM mode when possible.
> And last this change has a lot of impact on how we deal with UCM files. 
> The name of the card should reflect which codec is used, and the quirks 
> be added to the long name. If you lump everything with a single name 
> then you will make it really hard for userspace to figure out which 
> controls need to be set.
> 
> So nice idea but too early to merge. NAK.
Thank you for the review, will address these comments in the next version. When
you it be appropriate to re-submit? Are we waiting for any patches which are
queued to be merged soon?
> 
> > 
> > Signed-off-by: Shrirang Bagul 
> > ---
> >  sound/soc/intel/Kconfig   |  11 +--
> >  sound/soc/intel/atom/sst/sst_acpi.c   |   2 +
> >  sound/soc/intel/boards/bytcr_rt5640.c | 156 ++-
> > ---
> >  3 files changed, 147 insertions(+), 22 deletions(-)
> > 
> > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> > index fd5d1e0..0b43b6a 100644
> > --- a/sound/soc/intel/Kconfig
> > +++ b/sound/soc/intel/Kconfig
> > @@ -147,17 +147,18 @@ config SND_SOC_INTEL_BROADWELL_MACH
> >       If unsure select "N".
> > 
> >  config SND_SOC_INTEL_BYTCR_RT5640_MACH
> > -tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with
> > RT5640 codec"
> > +   tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with
> > RT5640/5660 codec"
> >     depends on X86 && I2C && ACPI
> >     select SND_SOC_RT5640
> > +   select SND_SOC_RT5660
> >     select SND_SST_MFLD_PLATFORM
> >     select SND_SST_IPC_ACPI
> >     select SND_SOC_INTEL_SST_MATCH if ACPI
> >     help
> > -  This adds support for ASoC machine driver for Intel(R) Baytrail
> > and Baytrail-CR
> > -  platforms with RT5640 audio codec.
> > -  Say Y if you have such a device.
> > -  If unsure select "N".
> > +     This adds support for ASoC machine driver for Intel(R) Baytrail
> > and Baytrail-CR
> > +     platforms with RT5640, RT5460 audio codec.
> > +     Say Y if you have such a device.
> > +     If unsure select "N".
> > 
> >  config SND_SOC_INTEL_BYTCR_RT5651_MACH
> >  tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with
> > RT5651 codec"
> > diff --git a/sound/soc/intel/atom/sst/sst_acpi.c
> > b/sound/soc/intel/atom/sst/sst_acpi.c
> > index f4d92bb..d401457f 100644
> > --- a/sound/soc/intel/atom/sst/sst_acpi.c
> > +++ b/sound/soc/intel/atom/sst/sst_acpi.c
> > @@ -441,6 +441,8 @@ static struct sst_acpi_mach sst_acpi_bytcr[] = {
> >     _rvp_platform_data },
> >     {"10EC5642", "bytcr_rt5640", "intel/fw_sst_0f28.bin",
> > "bytcr_rt5640", NULL,
> >     _rvp_platform_data },
> > +   {"10EC3277", "bytcr_rt5640", "intel/fw_sst_0f28.bin",
> > "bytcr_rt5640", NULL,
> > +   _rvp_platform_data },
> 
> so right there you add an HID in the platform driver and you need the 
> same in the platform driver to determine which codec type this is...
> 
> >     {"INTCCFFD", "bytcr_rt5640", "intel/fw_sst_0f28.bin",
> > "bytcr_rt5640", NULL,
> >     _rvp_platform_data },
> >     {"10EC5651", "bytcr_rt5651", "intel/fw_sst_0f28.bin",
> > "bytcr_rt5651", NULL,
> > diff --git a/sound/soc/intel/boards/bytcr_rt5640.c
> > b/sound/soc/intel/boards/bytcr_rt5640.c
> > index f6fd397..e8c9a01 100644
> > --- a/sound/soc/intel/boards/bytcr_rt5640.c
> > +++ b/sound/soc/intel/boards/bytcr_rt5640.c
> > @@ -32,11 +32,17 @@
> >  #include 
> >  #include 
> >  #include "../../codecs/rt5640.h"
>

[PATCH v2 3/4] ASoC: Intel: Support rt5660 codec for Baytrail

2017-01-12 Thread Shrirang Bagul
rt5660 and rt5640 are similar codecs so reuse the bytcr_rt5640 driver.
RT5660 codec is used on Dell Edge IoT Gateways with ACPI ID 10EC3277.
These devices sport only Line-In and Line-Out jacks.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 sound/soc/intel/Kconfig   |  11 +--
 sound/soc/intel/atom/sst/sst_acpi.c   |   2 +
 sound/soc/intel/boards/bytcr_rt5640.c | 156 ++
 3 files changed, 147 insertions(+), 22 deletions(-)

diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
index fd5d1e0..0b43b6a 100644
--- a/sound/soc/intel/Kconfig
+++ b/sound/soc/intel/Kconfig
@@ -147,17 +147,18 @@ config SND_SOC_INTEL_BROADWELL_MACH
  If unsure select "N".
 
 config SND_SOC_INTEL_BYTCR_RT5640_MACH
-tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with 
RT5640 codec"
+   tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with 
RT5640/5660 codec"
depends on X86 && I2C && ACPI
select SND_SOC_RT5640
+   select SND_SOC_RT5660
select SND_SST_MFLD_PLATFORM
select SND_SST_IPC_ACPI
select SND_SOC_INTEL_SST_MATCH if ACPI
help
-  This adds support for ASoC machine driver for Intel(R) Baytrail and 
Baytrail-CR
-  platforms with RT5640 audio codec.
-  Say Y if you have such a device.
-  If unsure select "N".
+ This adds support for ASoC machine driver for Intel(R) Baytrail and 
Baytrail-CR
+ platforms with RT5640, RT5460 audio codec.
+ Say Y if you have such a device.
+ If unsure select "N".
 
 config SND_SOC_INTEL_BYTCR_RT5651_MACH
 tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with 
RT5651 codec"
diff --git a/sound/soc/intel/atom/sst/sst_acpi.c 
b/sound/soc/intel/atom/sst/sst_acpi.c
index f4d92bb..d401457f 100644
--- a/sound/soc/intel/atom/sst/sst_acpi.c
+++ b/sound/soc/intel/atom/sst/sst_acpi.c
@@ -441,6 +441,8 @@ static struct sst_acpi_mach sst_acpi_bytcr[] = {
_rvp_platform_data },
{"10EC5642", "bytcr_rt5640", "intel/fw_sst_0f28.bin", "bytcr_rt5640", 
NULL,
_rvp_platform_data },
+   {"10EC3277", "bytcr_rt5640", "intel/fw_sst_0f28.bin", "bytcr_rt5640", 
NULL,
+   _rvp_platform_data },
{"INTCCFFD", "bytcr_rt5640", "intel/fw_sst_0f28.bin", "bytcr_rt5640", 
NULL,
_rvp_platform_data },
{"10EC5651", "bytcr_rt5651", "intel/fw_sst_0f28.bin", "bytcr_rt5651", 
NULL,
diff --git a/sound/soc/intel/boards/bytcr_rt5640.c 
b/sound/soc/intel/boards/bytcr_rt5640.c
index f6fd397..e8c9a01 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -32,11 +32,17 @@
 #include 
 #include 
 #include "../../codecs/rt5640.h"
+#include "../../codecs/rt5660.h"
 #include "../atom/sst-atom-controls.h"
 #include "../common/sst-acpi.h"
 #include "../common/sst-dsp.h"
 
 enum {
+   CODEC_TYPE_RT5640,
+   CODEC_TYPE_RT5660,
+};
+
+enum {
BYT_RT5640_DMIC1_MAP,
BYT_RT5640_DMIC2_MAP,
BYT_RT5640_IN1_MAP,
@@ -60,8 +66,16 @@ enum {
PLL1_MCLK,
 };
 
+struct byt_acpi_card {
+   char *codec_id;
+   int codec_type;
+   struct snd_soc_card *soc_card;
+};
+
 struct byt_rt5640_private {
+   struct byt_acpi_card *acpi_card;
struct clk *mclk;
+   char codec_name[16];
int *clks;
 };
 
@@ -72,6 +86,13 @@ static int byt_rt5640_clks[] = {
RT5640_PLL1_S_MCLK
 };
 
+static int byt_rt5660_clks[] = {
+   RT5660_SCLK_S_PLL1,
+   RT5660_SCLK_S_RCCLK,
+   RT5660_PLL1_S_BCLK,
+   RT5660_PLL1_S_MCLK
+};
+
 static unsigned long byt_rt5640_quirk = BYT_RT5640_MCLK_EN;
 
 static void log_quirks(struct device *dev)
@@ -105,6 +126,7 @@ static void log_quirks(struct device *dev)
 
 #define BYT_CODEC_DAI1 "rt5640-aif1"
 #define BYT_CODEC_DAI2 "rt5640-aif2"
+#define BYT_CODEC_DAI3 "rt5660-aif1"
 
 static inline struct snd_soc_dai *byt_get_codec_dai(struct snd_soc_card *card)
 {
@@ -117,6 +139,9 @@ static inline struct snd_soc_dai *byt_get_codec_dai(struct 
snd_soc_card *card)
if (!strncmp(rtd->codec_dai->name, BYT_CODEC_DAI2,
strlen(BYT_CODEC_DAI2)))
return rtd->codec_dai;
+   if (!strncmp(rtd->codec_dai->name, BYT_CODEC_DAI3,
+   strlen(BYT_CODEC_DAI3)))
+   return rtd->codec_dai;
 
}
return NULL;
@@ -269,6

[PATCH v2 3/4] ASoC: Intel: Support rt5660 codec for Baytrail

2017-01-12 Thread Shrirang Bagul
rt5660 and rt5640 are similar codecs so reuse the bytcr_rt5640 driver.
RT5660 codec is used on Dell Edge IoT Gateways with ACPI ID 10EC3277.
These devices sport only Line-In and Line-Out jacks.

Signed-off-by: Shrirang Bagul 
---
 sound/soc/intel/Kconfig   |  11 +--
 sound/soc/intel/atom/sst/sst_acpi.c   |   2 +
 sound/soc/intel/boards/bytcr_rt5640.c | 156 ++
 3 files changed, 147 insertions(+), 22 deletions(-)

diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
index fd5d1e0..0b43b6a 100644
--- a/sound/soc/intel/Kconfig
+++ b/sound/soc/intel/Kconfig
@@ -147,17 +147,18 @@ config SND_SOC_INTEL_BROADWELL_MACH
  If unsure select "N".
 
 config SND_SOC_INTEL_BYTCR_RT5640_MACH
-tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with 
RT5640 codec"
+   tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with 
RT5640/5660 codec"
depends on X86 && I2C && ACPI
select SND_SOC_RT5640
+   select SND_SOC_RT5660
select SND_SST_MFLD_PLATFORM
select SND_SST_IPC_ACPI
select SND_SOC_INTEL_SST_MATCH if ACPI
help
-  This adds support for ASoC machine driver for Intel(R) Baytrail and 
Baytrail-CR
-  platforms with RT5640 audio codec.
-  Say Y if you have such a device.
-  If unsure select "N".
+ This adds support for ASoC machine driver for Intel(R) Baytrail and 
Baytrail-CR
+ platforms with RT5640, RT5460 audio codec.
+ Say Y if you have such a device.
+ If unsure select "N".
 
 config SND_SOC_INTEL_BYTCR_RT5651_MACH
 tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with 
RT5651 codec"
diff --git a/sound/soc/intel/atom/sst/sst_acpi.c 
b/sound/soc/intel/atom/sst/sst_acpi.c
index f4d92bb..d401457f 100644
--- a/sound/soc/intel/atom/sst/sst_acpi.c
+++ b/sound/soc/intel/atom/sst/sst_acpi.c
@@ -441,6 +441,8 @@ static struct sst_acpi_mach sst_acpi_bytcr[] = {
_rvp_platform_data },
{"10EC5642", "bytcr_rt5640", "intel/fw_sst_0f28.bin", "bytcr_rt5640", 
NULL,
_rvp_platform_data },
+   {"10EC3277", "bytcr_rt5640", "intel/fw_sst_0f28.bin", "bytcr_rt5640", 
NULL,
+   _rvp_platform_data },
{"INTCCFFD", "bytcr_rt5640", "intel/fw_sst_0f28.bin", "bytcr_rt5640", 
NULL,
_rvp_platform_data },
{"10EC5651", "bytcr_rt5651", "intel/fw_sst_0f28.bin", "bytcr_rt5651", 
NULL,
diff --git a/sound/soc/intel/boards/bytcr_rt5640.c 
b/sound/soc/intel/boards/bytcr_rt5640.c
index f6fd397..e8c9a01 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -32,11 +32,17 @@
 #include 
 #include 
 #include "../../codecs/rt5640.h"
+#include "../../codecs/rt5660.h"
 #include "../atom/sst-atom-controls.h"
 #include "../common/sst-acpi.h"
 #include "../common/sst-dsp.h"
 
 enum {
+   CODEC_TYPE_RT5640,
+   CODEC_TYPE_RT5660,
+};
+
+enum {
BYT_RT5640_DMIC1_MAP,
BYT_RT5640_DMIC2_MAP,
BYT_RT5640_IN1_MAP,
@@ -60,8 +66,16 @@ enum {
PLL1_MCLK,
 };
 
+struct byt_acpi_card {
+   char *codec_id;
+   int codec_type;
+   struct snd_soc_card *soc_card;
+};
+
 struct byt_rt5640_private {
+   struct byt_acpi_card *acpi_card;
struct clk *mclk;
+   char codec_name[16];
int *clks;
 };
 
@@ -72,6 +86,13 @@ static int byt_rt5640_clks[] = {
RT5640_PLL1_S_MCLK
 };
 
+static int byt_rt5660_clks[] = {
+   RT5660_SCLK_S_PLL1,
+   RT5660_SCLK_S_RCCLK,
+   RT5660_PLL1_S_BCLK,
+   RT5660_PLL1_S_MCLK
+};
+
 static unsigned long byt_rt5640_quirk = BYT_RT5640_MCLK_EN;
 
 static void log_quirks(struct device *dev)
@@ -105,6 +126,7 @@ static void log_quirks(struct device *dev)
 
 #define BYT_CODEC_DAI1 "rt5640-aif1"
 #define BYT_CODEC_DAI2 "rt5640-aif2"
+#define BYT_CODEC_DAI3 "rt5660-aif1"
 
 static inline struct snd_soc_dai *byt_get_codec_dai(struct snd_soc_card *card)
 {
@@ -117,6 +139,9 @@ static inline struct snd_soc_dai *byt_get_codec_dai(struct 
snd_soc_card *card)
if (!strncmp(rtd->codec_dai->name, BYT_CODEC_DAI2,
strlen(BYT_CODEC_DAI2)))
return rtd->codec_dai;
+   if (!strncmp(rtd->codec_dai->name, BYT_CODEC_DAI3,
+   strlen(BYT_CODEC_DAI3)))
+   return rtd->codec_dai;
 
}
return NULL;
@@ -269,6 +294,

[PATCH v2 4/4] ASoC: Intel: bytcr_rt5640: Support line-out mute gpio

2017-01-12 Thread Shrirang Bagul
This patch adds support to toggle mute on 'line-out' pin on Dell Edge
IoT Gateways. A dedicated GPIO on the SoC is used to control the amplifier.
This GPIO is described in the BIOS DSD table.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 sound/soc/intel/boards/bytcr_rt5640.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5640.c 
b/sound/soc/intel/boards/bytcr_rt5640.c
index e8c9a01..ae53a29 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -74,6 +75,7 @@ struct byt_acpi_card {
 
 struct byt_rt5640_private {
struct byt_acpi_card *acpi_card;
+   struct gpio_desc *gpio_lo_mute;
struct clk *mclk;
char codec_name[16];
int *clks;
@@ -198,6 +200,19 @@ static int platform_clock_control(struct 
snd_soc_dapm_widget *w,
return 0;
 }
 
+static int byt_rt5660_event_lineout(struct snd_soc_dapm_widget *w,
+   struct snd_kcontrol *k, int event)
+{
+   struct snd_soc_dapm_context *dapm = w->dapm;
+   struct snd_soc_card *card = dapm->card;
+   struct byt_rt5640_private *priv = snd_soc_card_get_drvdata(card);
+
+   gpiod_set_value_cansleep(priv->gpio_lo_mute,
+   !(SND_SOC_DAPM_EVENT_ON(event)));
+
+   return 0;
+}
+
 static const struct snd_soc_dapm_widget byt_rt5640_widgets[] = {
SND_SOC_DAPM_HP("Headphone", NULL),
SND_SOC_DAPM_MIC("Headset Mic", NULL),
@@ -296,7 +311,7 @@ static const struct snd_kcontrol_new byt_rt5640_controls[] 
= {
 
 static const struct snd_soc_dapm_widget byt_rt5660_widgets[] = {
SND_SOC_DAPM_MIC("Line In", NULL),
-   SND_SOC_DAPM_LINE("Line Out", NULL),
+   SND_SOC_DAPM_LINE("Line Out", byt_rt5660_event_lineout),
SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0,
platform_clock_control, SND_SOC_DAPM_PRE_PMU |
SND_SOC_DAPM_POST_PMD),
@@ -562,7 +577,18 @@ static int byt_rt5640_init(struct snd_soc_pcm_runtime 
*runtime)
 static int byt_rt5660_init(struct snd_soc_pcm_runtime *runtime)
 {
int ret;
+   struct snd_soc_codec *codec = runtime->codec;
struct snd_soc_card *card = runtime->card;
+   struct byt_rt5640_private *priv = snd_soc_card_get_drvdata(card);
+
+   /* Request rt5660 GPIO for lineout mute control */
+   priv->gpio_lo_mute = devm_gpiod_get_index(codec->dev,
+   "lineout-mute", 0, 0);
+   if (IS_ERR(priv->gpio_lo_mute)) {
+   dev_err(card->dev, "Can't find GPIO_MUTE# gpio\n");
+   return PTR_ERR(priv->gpio_lo_mute);
+   }
+   gpiod_direction_output(priv->gpio_lo_mute, 1);
 
ret = snd_soc_dapm_add_routes(>dapm,
byt_rt5640_ssp2_aif1_map,
-- 
2.9.3



[PATCH v2 4/4] ASoC: Intel: bytcr_rt5640: Support line-out mute gpio

2017-01-12 Thread Shrirang Bagul
This patch adds support to toggle mute on 'line-out' pin on Dell Edge
IoT Gateways. A dedicated GPIO on the SoC is used to control the amplifier.
This GPIO is described in the BIOS DSD table.

Signed-off-by: Shrirang Bagul 
---
 sound/soc/intel/boards/bytcr_rt5640.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5640.c 
b/sound/soc/intel/boards/bytcr_rt5640.c
index e8c9a01..ae53a29 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -74,6 +75,7 @@ struct byt_acpi_card {
 
 struct byt_rt5640_private {
struct byt_acpi_card *acpi_card;
+   struct gpio_desc *gpio_lo_mute;
struct clk *mclk;
char codec_name[16];
int *clks;
@@ -198,6 +200,19 @@ static int platform_clock_control(struct 
snd_soc_dapm_widget *w,
return 0;
 }
 
+static int byt_rt5660_event_lineout(struct snd_soc_dapm_widget *w,
+   struct snd_kcontrol *k, int event)
+{
+   struct snd_soc_dapm_context *dapm = w->dapm;
+   struct snd_soc_card *card = dapm->card;
+   struct byt_rt5640_private *priv = snd_soc_card_get_drvdata(card);
+
+   gpiod_set_value_cansleep(priv->gpio_lo_mute,
+   !(SND_SOC_DAPM_EVENT_ON(event)));
+
+   return 0;
+}
+
 static const struct snd_soc_dapm_widget byt_rt5640_widgets[] = {
SND_SOC_DAPM_HP("Headphone", NULL),
SND_SOC_DAPM_MIC("Headset Mic", NULL),
@@ -296,7 +311,7 @@ static const struct snd_kcontrol_new byt_rt5640_controls[] 
= {
 
 static const struct snd_soc_dapm_widget byt_rt5660_widgets[] = {
SND_SOC_DAPM_MIC("Line In", NULL),
-   SND_SOC_DAPM_LINE("Line Out", NULL),
+   SND_SOC_DAPM_LINE("Line Out", byt_rt5660_event_lineout),
SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0,
platform_clock_control, SND_SOC_DAPM_PRE_PMU |
SND_SOC_DAPM_POST_PMD),
@@ -562,7 +577,18 @@ static int byt_rt5640_init(struct snd_soc_pcm_runtime 
*runtime)
 static int byt_rt5660_init(struct snd_soc_pcm_runtime *runtime)
 {
int ret;
+   struct snd_soc_codec *codec = runtime->codec;
struct snd_soc_card *card = runtime->card;
+   struct byt_rt5640_private *priv = snd_soc_card_get_drvdata(card);
+
+   /* Request rt5660 GPIO for lineout mute control */
+   priv->gpio_lo_mute = devm_gpiod_get_index(codec->dev,
+   "lineout-mute", 0, 0);
+   if (IS_ERR(priv->gpio_lo_mute)) {
+   dev_err(card->dev, "Can't find GPIO_MUTE# gpio\n");
+   return PTR_ERR(priv->gpio_lo_mute);
+   }
+   gpiod_direction_output(priv->gpio_lo_mute, 1);
 
ret = snd_soc_dapm_add_routes(>dapm,
byt_rt5640_ssp2_aif1_map,
-- 
2.9.3



[PATCH v2 1/4] ASoC: rt5660: Add ACPI support

2017-01-12 Thread Shrirang Bagul
On Dell IoT Gateways, RT5660 codec is available with ACPI ID 10EC3277.
Also, GPIO's are only available by index, so we register mappings to allow
machine drivers to access them by name.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 sound/soc/codecs/rt5660.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/sound/soc/codecs/rt5660.c b/sound/soc/codecs/rt5660.c
index 76cf76a..06cdcec 100644
--- a/sound/soc/codecs/rt5660.c
+++ b/sound/soc/codecs/rt5660.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -40,6 +41,12 @@
 
 #define RT5660_PR_BASE (RT5660_PR_RANGE_BASE + (0 * RT5660_PR_SPACING))
 
+/* GPIO indexes defined by ACPI */
+enum {
+   RT5660_GPIO_WAKE_INTR   = 0,
+   RT5660_GPIO_LINEOUT_MUTE= 1,
+};
+
 static const struct regmap_range_cfg rt5660_ranges[] = {
{ .name = "PR", .range_min = RT5660_PR_BASE,
  .range_max = RT5660_PR_BASE + 0xf3,
@@ -1245,10 +1252,31 @@ MODULE_DEVICE_TABLE(of, rt5660_of_match);
 
 static const struct acpi_device_id rt5660_acpi_match[] = {
{ "10EC5660", 0 },
+   { "10EC3277", 0 },
{ },
 };
 MODULE_DEVICE_TABLE(acpi, rt5660_acpi_match);
 
+static const struct acpi_gpio_params audio_wake_intr_gpio = { 
RT5660_GPIO_WAKE_INTR, 0, false };
+static const struct acpi_gpio_params lineout_mute_gpio = { 
RT5660_GPIO_LINEOUT_MUTE, 0, true };
+
+static const struct acpi_gpio_mapping byt_rt5660_gpios[] = {
+   { "audio-wake-intr-gpios", _wake_intr_gpio, 1 },
+   { "lineout-mute-gpios", _mute_gpio, 1 },
+   { NULL },
+};
+
+static void rt5660_read_acpi_properties(struct rt5660_priv *rt5660,
+   struct device *dev)
+{
+   int ret;
+
+   ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev),
+   byt_rt5660_gpios);
+   if (ret)
+   dev_warn(dev, "Failed to add driver gpios\n");
+}
+
 static int rt5660_parse_dt(struct rt5660_priv *rt5660, struct device *dev)
 {
rt5660->pdata.in1_diff = device_property_read_bool(dev,
@@ -1288,6 +1316,10 @@ static int rt5660_i2c_probe(struct i2c_client *i2c,
rt5660->pdata = *pdata;
else if (i2c->dev.of_node)
rt5660_parse_dt(rt5660, >dev);
+   else if (ACPI_HANDLE(>dev))
+   rt5660_read_acpi_properties(rt5660, >dev);
+   else
+   return -EINVAL;
 
rt5660->regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(rt5660->regmap)) {
-- 
2.9.3



[PATCH v2 1/4] ASoC: rt5660: Add ACPI support

2017-01-12 Thread Shrirang Bagul
On Dell IoT Gateways, RT5660 codec is available with ACPI ID 10EC3277.
Also, GPIO's are only available by index, so we register mappings to allow
machine drivers to access them by name.

Signed-off-by: Shrirang Bagul 
---
 sound/soc/codecs/rt5660.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/sound/soc/codecs/rt5660.c b/sound/soc/codecs/rt5660.c
index 76cf76a..06cdcec 100644
--- a/sound/soc/codecs/rt5660.c
+++ b/sound/soc/codecs/rt5660.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -40,6 +41,12 @@
 
 #define RT5660_PR_BASE (RT5660_PR_RANGE_BASE + (0 * RT5660_PR_SPACING))
 
+/* GPIO indexes defined by ACPI */
+enum {
+   RT5660_GPIO_WAKE_INTR   = 0,
+   RT5660_GPIO_LINEOUT_MUTE= 1,
+};
+
 static const struct regmap_range_cfg rt5660_ranges[] = {
{ .name = "PR", .range_min = RT5660_PR_BASE,
  .range_max = RT5660_PR_BASE + 0xf3,
@@ -1245,10 +1252,31 @@ MODULE_DEVICE_TABLE(of, rt5660_of_match);
 
 static const struct acpi_device_id rt5660_acpi_match[] = {
{ "10EC5660", 0 },
+   { "10EC3277", 0 },
{ },
 };
 MODULE_DEVICE_TABLE(acpi, rt5660_acpi_match);
 
+static const struct acpi_gpio_params audio_wake_intr_gpio = { 
RT5660_GPIO_WAKE_INTR, 0, false };
+static const struct acpi_gpio_params lineout_mute_gpio = { 
RT5660_GPIO_LINEOUT_MUTE, 0, true };
+
+static const struct acpi_gpio_mapping byt_rt5660_gpios[] = {
+   { "audio-wake-intr-gpios", _wake_intr_gpio, 1 },
+   { "lineout-mute-gpios", _mute_gpio, 1 },
+   { NULL },
+};
+
+static void rt5660_read_acpi_properties(struct rt5660_priv *rt5660,
+   struct device *dev)
+{
+   int ret;
+
+   ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev),
+   byt_rt5660_gpios);
+   if (ret)
+   dev_warn(dev, "Failed to add driver gpios\n");
+}
+
 static int rt5660_parse_dt(struct rt5660_priv *rt5660, struct device *dev)
 {
rt5660->pdata.in1_diff = device_property_read_bool(dev,
@@ -1288,6 +1316,10 @@ static int rt5660_i2c_probe(struct i2c_client *i2c,
rt5660->pdata = *pdata;
else if (i2c->dev.of_node)
rt5660_parse_dt(rt5660, >dev);
+   else if (ACPI_HANDLE(>dev))
+   rt5660_read_acpi_properties(rt5660, >dev);
+   else
+   return -EINVAL;
 
rt5660->regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(rt5660->regmap)) {
-- 
2.9.3



[PATCH v2 2/4] ASoC: Intel: bytcr_rt5640: move codec clks to card driver data

2017-01-12 Thread Shrirang Bagul
This patch moves codec specific clock indices to card driver data.
Functions configuring clocks can be re-used for other codec chips with
similar features (viz. RT5660)

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 sound/soc/intel/boards/bytcr_rt5640.c | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5640.c 
b/sound/soc/intel/boards/bytcr_rt5640.c
index 1bd985f..f6fd397 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -53,8 +53,23 @@ enum {
 #define BYT_RT5640_MCLK_EN BIT(22)
 #define BYT_RT5640_MCLK_25MHZ  BIT(23)
 
+enum {
+   SCLK_PLL1 = 0,
+   SCLK_RCCLK,
+   PLL1_BCLK,
+   PLL1_MCLK,
+};
+
 struct byt_rt5640_private {
struct clk *mclk;
+   int *clks;
+};
+
+static int byt_rt5640_clks[] = {
+   RT5640_SCLK_S_PLL1,
+   RT5640_SCLK_S_RCCLK,
+   RT5640_PLL1_S_BCLK1,
+   RT5640_PLL1_S_MCLK
 };
 
 static unsigned long byt_rt5640_quirk = BYT_RT5640_MCLK_EN;
@@ -132,7 +147,7 @@ static int platform_clock_control(struct 
snd_soc_dapm_widget *w,
return ret;
}
}
-   ret = snd_soc_dai_set_sysclk(codec_dai, RT5640_SCLK_S_PLL1,
+   ret = snd_soc_dai_set_sysclk(codec_dai, priv->clks[SCLK_PLL1],
 48000 * 512,
 SND_SOC_CLOCK_IN);
} else {
@@ -141,7 +156,7 @@ static int platform_clock_control(struct 
snd_soc_dapm_widget *w,
 * turning off the platform clock. Codec needs clock
 * for Jack detection and button press
 */
-   ret = snd_soc_dai_set_sysclk(codec_dai, RT5640_SCLK_S_RCCLK,
+   ret = snd_soc_dai_set_sysclk(codec_dai, priv->clks[SCLK_RCCLK],
 48000 * 512,
 SND_SOC_CLOCK_IN);
if (!ret) {
@@ -259,6 +274,7 @@ static int byt_rt5640_aif1_hw_params(struct 
snd_pcm_substream *substream,
 {
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct snd_soc_dai *codec_dai = rtd->codec_dai;
+   struct byt_rt5640_private *priv = snd_soc_card_get_drvdata(rtd->card);
int ret;
 
ret = snd_soc_dai_set_sysclk(codec_dai, RT5640_SCLK_S_PLL1,
@@ -277,25 +293,25 @@ static int byt_rt5640_aif1_hw_params(struct 
snd_pcm_substream *substream,
 
/* 2x16 bit slots on SSP0 */
ret = snd_soc_dai_set_pll(codec_dai, 0,
-   RT5640_PLL1_S_BCLK1,
+   priv->clks[PLL1_BCLK],
params_rate(params) * 32,
params_rate(params) * 512);
} else {
/* 2x15 bit slots on SSP2 */
ret = snd_soc_dai_set_pll(codec_dai, 0,
-   RT5640_PLL1_S_BCLK1,
+   priv->clks[PLL1_BCLK],
params_rate(params) * 50,
params_rate(params) * 512);
}
} else {
if (byt_rt5640_quirk & BYT_RT5640_MCLK_25MHZ) {
ret = snd_soc_dai_set_pll(codec_dai, 0,
-   RT5640_PLL1_S_MCLK,
+   priv->clks[PLL1_MCLK],
2500,
params_rate(params) * 512);
} else {
ret = snd_soc_dai_set_pll(codec_dai, 0,
-   RT5640_PLL1_S_MCLK,
+   priv->clks[PLL1_MCLK],
1920,
params_rate(params) * 512);
}
@@ -717,6 +733,7 @@ static int snd_byt_rt5640_mc_probe(struct platform_device 
*pdev)
return -ENOMEM;
 
/* register the soc card */
+   priv->clks = byt_rt5640_clks;
byt_rt5640_card.dev = >dev;
mach = byt_rt5640_card.dev->platform_data;
snd_soc_card_set_drvdata(_rt5640_card, priv);
-- 
2.9.3



[PATCH v2 0/4] ASoC: Dell IoT Gateway audio support

2017-01-12 Thread Shrirang Bagul
This work is based on for-next branch of:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git

These patches add basic audio support on new Dell Edge IoT Gateways.
RT5660 codec is connected to SSP2 port on Intel Atom Baytrail E3815 SoC.
The machine driver is based on bytcr_rt5640. These devices have line-in and
line-out jacks with line-out mute enable gpio described in ACPI tables.

Since v1:
* rt5660: Use enumerations to define GPIO's described ACPI DSDT
* Initialize rt5660 controls from card struct
* Re-use existing bytcr_rt5640 machine driver to support rt5660 codec based
  audio

Shrirang Bagul (4):
  ASoC: rt5660: Add ACPI support
  ASoC: Intel: bytcr_rt5640: move codec clks to card driver data
  ASoC: Intel: Support rt5660 codec for Baytrail
  ASoC: Intel: bytcr_rt5640: Support line-out mute gpio

 sound/soc/codecs/rt5660.c |  32 ++
 sound/soc/intel/Kconfig   |  11 +-
 sound/soc/intel/atom/sst/sst_acpi.c   |   2 +
 sound/soc/intel/boards/bytcr_rt5640.c | 211 ++
 4 files changed, 228 insertions(+), 28 deletions(-)

-- 
2.9.3



[PATCH v2 2/4] ASoC: Intel: bytcr_rt5640: move codec clks to card driver data

2017-01-12 Thread Shrirang Bagul
This patch moves codec specific clock indices to card driver data.
Functions configuring clocks can be re-used for other codec chips with
similar features (viz. RT5660)

Signed-off-by: Shrirang Bagul 
---
 sound/soc/intel/boards/bytcr_rt5640.c | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/sound/soc/intel/boards/bytcr_rt5640.c 
b/sound/soc/intel/boards/bytcr_rt5640.c
index 1bd985f..f6fd397 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -53,8 +53,23 @@ enum {
 #define BYT_RT5640_MCLK_EN BIT(22)
 #define BYT_RT5640_MCLK_25MHZ  BIT(23)
 
+enum {
+   SCLK_PLL1 = 0,
+   SCLK_RCCLK,
+   PLL1_BCLK,
+   PLL1_MCLK,
+};
+
 struct byt_rt5640_private {
struct clk *mclk;
+   int *clks;
+};
+
+static int byt_rt5640_clks[] = {
+   RT5640_SCLK_S_PLL1,
+   RT5640_SCLK_S_RCCLK,
+   RT5640_PLL1_S_BCLK1,
+   RT5640_PLL1_S_MCLK
 };
 
 static unsigned long byt_rt5640_quirk = BYT_RT5640_MCLK_EN;
@@ -132,7 +147,7 @@ static int platform_clock_control(struct 
snd_soc_dapm_widget *w,
return ret;
}
}
-   ret = snd_soc_dai_set_sysclk(codec_dai, RT5640_SCLK_S_PLL1,
+   ret = snd_soc_dai_set_sysclk(codec_dai, priv->clks[SCLK_PLL1],
 48000 * 512,
 SND_SOC_CLOCK_IN);
} else {
@@ -141,7 +156,7 @@ static int platform_clock_control(struct 
snd_soc_dapm_widget *w,
 * turning off the platform clock. Codec needs clock
 * for Jack detection and button press
 */
-   ret = snd_soc_dai_set_sysclk(codec_dai, RT5640_SCLK_S_RCCLK,
+   ret = snd_soc_dai_set_sysclk(codec_dai, priv->clks[SCLK_RCCLK],
 48000 * 512,
 SND_SOC_CLOCK_IN);
if (!ret) {
@@ -259,6 +274,7 @@ static int byt_rt5640_aif1_hw_params(struct 
snd_pcm_substream *substream,
 {
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct snd_soc_dai *codec_dai = rtd->codec_dai;
+   struct byt_rt5640_private *priv = snd_soc_card_get_drvdata(rtd->card);
int ret;
 
ret = snd_soc_dai_set_sysclk(codec_dai, RT5640_SCLK_S_PLL1,
@@ -277,25 +293,25 @@ static int byt_rt5640_aif1_hw_params(struct 
snd_pcm_substream *substream,
 
/* 2x16 bit slots on SSP0 */
ret = snd_soc_dai_set_pll(codec_dai, 0,
-   RT5640_PLL1_S_BCLK1,
+   priv->clks[PLL1_BCLK],
params_rate(params) * 32,
params_rate(params) * 512);
} else {
/* 2x15 bit slots on SSP2 */
ret = snd_soc_dai_set_pll(codec_dai, 0,
-   RT5640_PLL1_S_BCLK1,
+   priv->clks[PLL1_BCLK],
params_rate(params) * 50,
params_rate(params) * 512);
}
} else {
if (byt_rt5640_quirk & BYT_RT5640_MCLK_25MHZ) {
ret = snd_soc_dai_set_pll(codec_dai, 0,
-   RT5640_PLL1_S_MCLK,
+   priv->clks[PLL1_MCLK],
2500,
params_rate(params) * 512);
} else {
ret = snd_soc_dai_set_pll(codec_dai, 0,
-   RT5640_PLL1_S_MCLK,
+   priv->clks[PLL1_MCLK],
1920,
params_rate(params) * 512);
}
@@ -717,6 +733,7 @@ static int snd_byt_rt5640_mc_probe(struct platform_device 
*pdev)
return -ENOMEM;
 
/* register the soc card */
+   priv->clks = byt_rt5640_clks;
byt_rt5640_card.dev = >dev;
mach = byt_rt5640_card.dev->platform_data;
snd_soc_card_set_drvdata(_rt5640_card, priv);
-- 
2.9.3



[PATCH v2 0/4] ASoC: Dell IoT Gateway audio support

2017-01-12 Thread Shrirang Bagul
This work is based on for-next branch of:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git

These patches add basic audio support on new Dell Edge IoT Gateways.
RT5660 codec is connected to SSP2 port on Intel Atom Baytrail E3815 SoC.
The machine driver is based on bytcr_rt5640. These devices have line-in and
line-out jacks with line-out mute enable gpio described in ACPI tables.

Since v1:
* rt5660: Use enumerations to define GPIO's described ACPI DSDT
* Initialize rt5660 controls from card struct
* Re-use existing bytcr_rt5640 machine driver to support rt5660 codec based
  audio

Shrirang Bagul (4):
  ASoC: rt5660: Add ACPI support
  ASoC: Intel: bytcr_rt5640: move codec clks to card driver data
  ASoC: Intel: Support rt5660 codec for Baytrail
  ASoC: Intel: bytcr_rt5640: Support line-out mute gpio

 sound/soc/codecs/rt5660.c |  32 ++
 sound/soc/intel/Kconfig   |  11 +-
 sound/soc/intel/atom/sst/sst_acpi.c   |   2 +
 sound/soc/intel/boards/bytcr_rt5640.c | 211 ++
 4 files changed, 228 insertions(+), 28 deletions(-)

-- 
2.9.3



Re: [alsa-devel] [PATCH 2/2] ASoC: Intel: boards: Add Baytrail RT5660 machine driver

2016-12-26 Thread Shrirang Bagul
On Tue, 2016-12-27 at 11:29 +0800, Shrirang Bagul wrote:
> On Mon, 2016-12-19 at 16:44 +, Mark Brown wrote:
> > On Mon, Dec 19, 2016 at 10:30:09AM -0600, Pierre-Louis Bossart wrote:
> > 
> > > All this code seems to be largely a copy-paste of the bytcr_rt5640 machine
> > > driver and the same comments would apply there. This patch did miss the
> > > last
> > 
> > Yes, there's a lot of room for cleanups in the existing code too (and of
> > course if there's such a large amount of cut'n'paste that implies that
> > there should be some code reuse going on).
> 
> Thank you for the review and valuable comments. Following the discussion so
> far,
> I feel the proper way would be to adapt bytcr_rt5660  machine driver to manage
> RT5660 codec.
typo, should be bytcr_rt5640
> > 
> > > correction merged by Mark to deal with errors "ASoC: Intel: bytcr_rt5640:
> > > fallback mechanism if MCLK is not enabled" and the same error handling
> > > would
> > > be needed.
> > 
> > There was a cut back version of it I thought?
> 
> Will try and include the MCLK fallback patch in ver. 2 of the patch.

signature.asc
Description: This is a digitally signed message part


Re: [alsa-devel] [PATCH 2/2] ASoC: Intel: boards: Add Baytrail RT5660 machine driver

2016-12-26 Thread Shrirang Bagul
On Tue, 2016-12-27 at 11:29 +0800, Shrirang Bagul wrote:
> On Mon, 2016-12-19 at 16:44 +, Mark Brown wrote:
> > On Mon, Dec 19, 2016 at 10:30:09AM -0600, Pierre-Louis Bossart wrote:
> > 
> > > All this code seems to be largely a copy-paste of the bytcr_rt5640 machine
> > > driver and the same comments would apply there. This patch did miss the
> > > last
> > 
> > Yes, there's a lot of room for cleanups in the existing code too (and of
> > course if there's such a large amount of cut'n'paste that implies that
> > there should be some code reuse going on).
> 
> Thank you for the review and valuable comments. Following the discussion so
> far,
> I feel the proper way would be to adapt bytcr_rt5660  machine driver to manage
> RT5660 codec.
typo, should be bytcr_rt5640
> > 
> > > correction merged by Mark to deal with errors "ASoC: Intel: bytcr_rt5640:
> > > fallback mechanism if MCLK is not enabled" and the same error handling
> > > would
> > > be needed.
> > 
> > There was a cut back version of it I thought?
> 
> Will try and include the MCLK fallback patch in ver. 2 of the patch.

signature.asc
Description: This is a digitally signed message part


Re: [PATCH 1/2] ASoC: rt5660: Add ACPI support

2016-12-26 Thread Shrirang Bagul
On Mon, 2016-12-19 at 15:44 +, Mark Brown wrote:
> On Mon, Dec 19, 2016 at 09:51:46PM +0800, Shrirang Bagul wrote:
> 
> > +static const struct acpi_gpio_params audio_wake_intr_gpio = { 0, 0, false
> > };
> > +static const struct acpi_gpio_params lineout_mute_gpio = { 1, 0, true };
> 
> Can we please write these in a fashion more idiomatic for the kernel and
> useful for human readers with named struct fields?
Okay, will update in ver. 2 of the patch. Thanks.

signature.asc
Description: This is a digitally signed message part


Re: [PATCH 1/2] ASoC: rt5660: Add ACPI support

2016-12-26 Thread Shrirang Bagul
On Mon, 2016-12-19 at 15:44 +, Mark Brown wrote:
> On Mon, Dec 19, 2016 at 09:51:46PM +0800, Shrirang Bagul wrote:
> 
> > +static const struct acpi_gpio_params audio_wake_intr_gpio = { 0, 0, false
> > };
> > +static const struct acpi_gpio_params lineout_mute_gpio = { 1, 0, true };
> 
> Can we please write these in a fashion more idiomatic for the kernel and
> useful for human readers with named struct fields?
Okay, will update in ver. 2 of the patch. Thanks.

signature.asc
Description: This is a digitally signed message part


Re: [alsa-devel] [PATCH 2/2] ASoC: Intel: boards: Add Baytrail RT5660 machine driver

2016-12-26 Thread Shrirang Bagul
On Mon, 2016-12-19 at 16:44 +, Mark Brown wrote:
> On Mon, Dec 19, 2016 at 10:30:09AM -0600, Pierre-Louis Bossart wrote:
> 
> > All this code seems to be largely a copy-paste of the bytcr_rt5640 machine
> > driver and the same comments would apply there. This patch did miss the last
> 
> Yes, there's a lot of room for cleanups in the existing code too (and of
> course if there's such a large amount of cut'n'paste that implies that
> there should be some code reuse going on).
Thank you for the review and valuable comments. Following the discussion so far,
I feel the proper way would be to adapt bytcr_rt5660  machine driver to manage
RT5660 codec.
> 
> > correction merged by Mark to deal with errors "ASoC: Intel: bytcr_rt5640:
> > fallback mechanism if MCLK is not enabled" and the same error handling would
> > be needed.
> 
> There was a cut back version of it I thought?
Will try and include the MCLK fallback patch in ver. 2 of the patch.

signature.asc
Description: This is a digitally signed message part


Re: [alsa-devel] [PATCH 2/2] ASoC: Intel: boards: Add Baytrail RT5660 machine driver

2016-12-26 Thread Shrirang Bagul
On Mon, 2016-12-19 at 16:44 +, Mark Brown wrote:
> On Mon, Dec 19, 2016 at 10:30:09AM -0600, Pierre-Louis Bossart wrote:
> 
> > All this code seems to be largely a copy-paste of the bytcr_rt5640 machine
> > driver and the same comments would apply there. This patch did miss the last
> 
> Yes, there's a lot of room for cleanups in the existing code too (and of
> course if there's such a large amount of cut'n'paste that implies that
> there should be some code reuse going on).
Thank you for the review and valuable comments. Following the discussion so far,
I feel the proper way would be to adapt bytcr_rt5660  machine driver to manage
RT5660 codec.
> 
> > correction merged by Mark to deal with errors "ASoC: Intel: bytcr_rt5640:
> > fallback mechanism if MCLK is not enabled" and the same error handling would
> > be needed.
> 
> There was a cut back version of it I thought?
Will try and include the MCLK fallback patch in ver. 2 of the patch.

signature.asc
Description: This is a digitally signed message part


[PATCH 2/2] ASoC: Intel: boards: Add Baytrail RT5660 machine driver

2016-12-19 Thread Shrirang Bagul
This is used by Dell Edge IoT Gateways.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 sound/soc/intel/Kconfig   |  13 +
 sound/soc/intel/atom/sst/sst_acpi.c   |   2 +
 sound/soc/intel/boards/Makefile   |   2 +
 sound/soc/intel/boards/bytcr_rt5660.c | 573 ++
 4 files changed, 590 insertions(+)
 create mode 100644 sound/soc/intel/boards/bytcr_rt5660.c

diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
index fd5d1e0..04027e6 100644
--- a/sound/soc/intel/Kconfig
+++ b/sound/soc/intel/Kconfig
@@ -172,6 +172,19 @@ config SND_SOC_INTEL_BYTCR_RT5651_MACH
   Say Y if you have such a device.
   If unsure select "N".
 
+config SND_SOC_INTEL_BYTCR_RT5660_MACH
+   tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with 
RT5660 codec"
+   depends on X86 && I2C && ACPI
+   select SND_SOC_RT5660
+   select SND_SST_MFLD_PLATFORM
+   select SND_SST_IPC_ACPI
+   select SND_SOC_INTEL_SST_MATCH if ACPI
+   help
+ This adds support for ASoC machine driver for Intel(R) Baytrail and 
Baytrail-CR
+ platforms with RT5660 audio codec.
+ Say Y if you have such a device.
+ If unsure select "N".
+
 config SND_SOC_INTEL_CHT_BSW_RT5672_MACH
 tristate "ASoC Audio driver for Intel Cherrytrail & Braswell with 
RT5672 codec"
 depends on X86_INTEL_LPSS && I2C && ACPI
diff --git a/sound/soc/intel/atom/sst/sst_acpi.c 
b/sound/soc/intel/atom/sst/sst_acpi.c
index f4d92bb..a7f8400 100644
--- a/sound/soc/intel/atom/sst/sst_acpi.c
+++ b/sound/soc/intel/atom/sst/sst_acpi.c
@@ -445,6 +445,8 @@ static struct sst_acpi_mach sst_acpi_bytcr[] = {
_rvp_platform_data },
{"10EC5651", "bytcr_rt5651", "intel/fw_sst_0f28.bin", "bytcr_rt5651", 
NULL,
_rvp_platform_data },
+   {"10EC3277", "bytcr_rt5660", "intel/fw_sst_0f28.bin", "bytcr_rt5660", 
NULL,
+   _rvp_platform_data },
{},
 };
 
diff --git a/sound/soc/intel/boards/Makefile b/sound/soc/intel/boards/Makefile
index 5639f10..32255ee 100644
--- a/sound/soc/intel/boards/Makefile
+++ b/sound/soc/intel/boards/Makefile
@@ -7,6 +7,7 @@ snd-soc-sst-bxt-da7219_max98357a-objs := bxt_da7219_max98357a.o
 snd-soc-sst-bxt-rt298-objs := bxt_rt298.o
 snd-soc-sst-bytcr-rt5640-objs := bytcr_rt5640.o
 snd-soc-sst-bytcr-rt5651-objs := bytcr_rt5651.o
+snd-soc-sst-bytcr-rt5660-objs := bytcr_rt5660.o
 snd-soc-sst-cht-bsw-rt5672-objs := cht_bsw_rt5672.o
 snd-soc-sst-cht-bsw-rt5645-objs := cht_bsw_rt5645.o
 snd-soc-sst-cht-bsw-max98090_ti-objs := cht_bsw_max98090_ti.o
@@ -23,6 +24,7 @@ obj-$(CONFIG_SND_SOC_INTEL_BROADWELL_MACH) += 
snd-soc-sst-broadwell.o
 obj-$(CONFIG_SND_SOC_INTEL_BDW_RT5677_MACH) += snd-soc-sst-bdw-rt5677-mach.o
 obj-$(CONFIG_SND_SOC_INTEL_BYTCR_RT5640_MACH) += snd-soc-sst-bytcr-rt5640.o
 obj-$(CONFIG_SND_SOC_INTEL_BYTCR_RT5651_MACH) += snd-soc-sst-bytcr-rt5651.o
+obj-$(CONFIG_SND_SOC_INTEL_BYTCR_RT5660_MACH) += snd-soc-sst-bytcr-rt5660.o
 obj-$(CONFIG_SND_SOC_INTEL_CHT_BSW_RT5672_MACH) += snd-soc-sst-cht-bsw-rt5672.o
 obj-$(CONFIG_SND_SOC_INTEL_CHT_BSW_RT5645_MACH) += snd-soc-sst-cht-bsw-rt5645.o
 obj-$(CONFIG_SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH) += 
snd-soc-sst-cht-bsw-max98090_ti.o
diff --git a/sound/soc/intel/boards/bytcr_rt5660.c 
b/sound/soc/intel/boards/bytcr_rt5660.c
new file mode 100644
index 000..0cd989d
--- /dev/null
+++ b/sound/soc/intel/boards/bytcr_rt5660.c
@@ -0,0 +1,573 @@
+/*
+ *  Intel Baytrail SST RT5660 machine driver
+ *  Copyright (C) 2016 Shrirang Bagul <shrirang.ba...@canonical.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ */
+
+#define DEBUG
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../../codecs/rt5660.h"
+#include "../atom/sst-atom-controls.h"
+#include "../common/sst-acpi.h"
+#include "../common/sst-dsp.h"
+
+#define BYT_RT5660_MAP(quirk)  ((quirk) & 0xff)
+#define BYT_RT5660_SSP0_AIF1   BIT(16)
+#define BYT_RT5660_MCLK_EN BIT(17)
+#define BYT_RT5660_MCLK_25MHZ  BIT(18)
+
+struct byt_rt5660_private {
+  

[PATCH 2/2] ASoC: Intel: boards: Add Baytrail RT5660 machine driver

2016-12-19 Thread Shrirang Bagul
This is used by Dell Edge IoT Gateways.

Signed-off-by: Shrirang Bagul 
---
 sound/soc/intel/Kconfig   |  13 +
 sound/soc/intel/atom/sst/sst_acpi.c   |   2 +
 sound/soc/intel/boards/Makefile   |   2 +
 sound/soc/intel/boards/bytcr_rt5660.c | 573 ++
 4 files changed, 590 insertions(+)
 create mode 100644 sound/soc/intel/boards/bytcr_rt5660.c

diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
index fd5d1e0..04027e6 100644
--- a/sound/soc/intel/Kconfig
+++ b/sound/soc/intel/Kconfig
@@ -172,6 +172,19 @@ config SND_SOC_INTEL_BYTCR_RT5651_MACH
   Say Y if you have such a device.
   If unsure select "N".
 
+config SND_SOC_INTEL_BYTCR_RT5660_MACH
+   tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with 
RT5660 codec"
+   depends on X86 && I2C && ACPI
+   select SND_SOC_RT5660
+   select SND_SST_MFLD_PLATFORM
+   select SND_SST_IPC_ACPI
+   select SND_SOC_INTEL_SST_MATCH if ACPI
+   help
+ This adds support for ASoC machine driver for Intel(R) Baytrail and 
Baytrail-CR
+ platforms with RT5660 audio codec.
+ Say Y if you have such a device.
+ If unsure select "N".
+
 config SND_SOC_INTEL_CHT_BSW_RT5672_MACH
 tristate "ASoC Audio driver for Intel Cherrytrail & Braswell with 
RT5672 codec"
 depends on X86_INTEL_LPSS && I2C && ACPI
diff --git a/sound/soc/intel/atom/sst/sst_acpi.c 
b/sound/soc/intel/atom/sst/sst_acpi.c
index f4d92bb..a7f8400 100644
--- a/sound/soc/intel/atom/sst/sst_acpi.c
+++ b/sound/soc/intel/atom/sst/sst_acpi.c
@@ -445,6 +445,8 @@ static struct sst_acpi_mach sst_acpi_bytcr[] = {
_rvp_platform_data },
{"10EC5651", "bytcr_rt5651", "intel/fw_sst_0f28.bin", "bytcr_rt5651", 
NULL,
_rvp_platform_data },
+   {"10EC3277", "bytcr_rt5660", "intel/fw_sst_0f28.bin", "bytcr_rt5660", 
NULL,
+   _rvp_platform_data },
{},
 };
 
diff --git a/sound/soc/intel/boards/Makefile b/sound/soc/intel/boards/Makefile
index 5639f10..32255ee 100644
--- a/sound/soc/intel/boards/Makefile
+++ b/sound/soc/intel/boards/Makefile
@@ -7,6 +7,7 @@ snd-soc-sst-bxt-da7219_max98357a-objs := bxt_da7219_max98357a.o
 snd-soc-sst-bxt-rt298-objs := bxt_rt298.o
 snd-soc-sst-bytcr-rt5640-objs := bytcr_rt5640.o
 snd-soc-sst-bytcr-rt5651-objs := bytcr_rt5651.o
+snd-soc-sst-bytcr-rt5660-objs := bytcr_rt5660.o
 snd-soc-sst-cht-bsw-rt5672-objs := cht_bsw_rt5672.o
 snd-soc-sst-cht-bsw-rt5645-objs := cht_bsw_rt5645.o
 snd-soc-sst-cht-bsw-max98090_ti-objs := cht_bsw_max98090_ti.o
@@ -23,6 +24,7 @@ obj-$(CONFIG_SND_SOC_INTEL_BROADWELL_MACH) += 
snd-soc-sst-broadwell.o
 obj-$(CONFIG_SND_SOC_INTEL_BDW_RT5677_MACH) += snd-soc-sst-bdw-rt5677-mach.o
 obj-$(CONFIG_SND_SOC_INTEL_BYTCR_RT5640_MACH) += snd-soc-sst-bytcr-rt5640.o
 obj-$(CONFIG_SND_SOC_INTEL_BYTCR_RT5651_MACH) += snd-soc-sst-bytcr-rt5651.o
+obj-$(CONFIG_SND_SOC_INTEL_BYTCR_RT5660_MACH) += snd-soc-sst-bytcr-rt5660.o
 obj-$(CONFIG_SND_SOC_INTEL_CHT_BSW_RT5672_MACH) += snd-soc-sst-cht-bsw-rt5672.o
 obj-$(CONFIG_SND_SOC_INTEL_CHT_BSW_RT5645_MACH) += snd-soc-sst-cht-bsw-rt5645.o
 obj-$(CONFIG_SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH) += 
snd-soc-sst-cht-bsw-max98090_ti.o
diff --git a/sound/soc/intel/boards/bytcr_rt5660.c 
b/sound/soc/intel/boards/bytcr_rt5660.c
new file mode 100644
index 000..0cd989d
--- /dev/null
+++ b/sound/soc/intel/boards/bytcr_rt5660.c
@@ -0,0 +1,573 @@
+/*
+ *  Intel Baytrail SST RT5660 machine driver
+ *  Copyright (C) 2016 Shrirang Bagul 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ */
+
+#define DEBUG
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../../codecs/rt5660.h"
+#include "../atom/sst-atom-controls.h"
+#include "../common/sst-acpi.h"
+#include "../common/sst-dsp.h"
+
+#define BYT_RT5660_MAP(quirk)  ((quirk) & 0xff)
+#define BYT_RT5660_SSP0_AIF1   BIT(16)
+#define BYT_RT5660_MCLK_EN BIT(17)
+#define BYT_RT5660_MCLK_25MHZ  BIT(18)
+
+struct byt_rt5660_private {
+   struct clk *mclk;
+   struct gpio_desc *gpio_lo_mute;
+};
+
+

[PATCH 0/2] ASoC: Dell IoT Gateway audio support

2016-12-19 Thread Shrirang Bagul
These patches add basic audio support on new Dell Edge IoT Gateways.
RT5660 codec is connected to SSP2 port on Intel Atom Baytrail E3815 SoC.
The machine driver is based on bytcr_rt5640. These devices have line-in and
line-out jacks with line-out mute enable gpio described in ACPI tables.

Shrirang Bagul (2):
  ASoC: rt5660: Add ACPI support
  ASoC: Intel: boards: Add Baytrail RT5660 machine driver

 sound/soc/codecs/rt5660.c |  26 ++
 sound/soc/intel/Kconfig   |  13 +
 sound/soc/intel/atom/sst/sst_acpi.c   |   2 +
 sound/soc/intel/boards/Makefile   |   2 +
 sound/soc/intel/boards/bytcr_rt5660.c | 573 ++
 5 files changed, 616 insertions(+)
 create mode 100644 sound/soc/intel/boards/bytcr_rt5660.c

-- 
2.9.3



[PATCH 1/2] ASoC: rt5660: Add ACPI support

2016-12-19 Thread Shrirang Bagul
On Dell IoT Gateways, RT5660 codec is available with ACPI ID 10EC3277.
Also, GPIO's are only available by index, so we register mappings to allow
machine drivers to access them by name.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 sound/soc/codecs/rt5660.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/sound/soc/codecs/rt5660.c b/sound/soc/codecs/rt5660.c
index 76cf76a..c8bdeb3 100644
--- a/sound/soc/codecs/rt5660.c
+++ b/sound/soc/codecs/rt5660.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1245,10 +1246,31 @@ MODULE_DEVICE_TABLE(of, rt5660_of_match);
 
 static const struct acpi_device_id rt5660_acpi_match[] = {
{ "10EC5660", 0 },
+   { "10EC3277", 0 },
{ },
 };
 MODULE_DEVICE_TABLE(acpi, rt5660_acpi_match);
 
+static const struct acpi_gpio_params audio_wake_intr_gpio = { 0, 0, false };
+static const struct acpi_gpio_params lineout_mute_gpio = { 1, 0, true };
+
+static const struct acpi_gpio_mapping byt_rt5660_gpios[] = {
+   { "audio-wake-intr-gpios", _wake_intr_gpio, 1 },
+   { "lineout-mute-gpios", _mute_gpio, 1 },
+   { NULL },
+};
+
+static void rt5660_read_acpi_properties(struct rt5660_priv *rt5660,
+   struct device *dev)
+{
+   int ret;
+
+   ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev),
+   byt_rt5660_gpios);
+   if (ret)
+   dev_warn(dev, "Failed to add driver gpios\n");
+}
+
 static int rt5660_parse_dt(struct rt5660_priv *rt5660, struct device *dev)
 {
rt5660->pdata.in1_diff = device_property_read_bool(dev,
@@ -1288,6 +1310,10 @@ static int rt5660_i2c_probe(struct i2c_client *i2c,
rt5660->pdata = *pdata;
else if (i2c->dev.of_node)
rt5660_parse_dt(rt5660, >dev);
+   else if (ACPI_HANDLE(>dev))
+   rt5660_read_acpi_properties(rt5660, >dev);
+   else
+   return -EINVAL;
 
rt5660->regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(rt5660->regmap)) {
-- 
2.9.3



[PATCH 0/2] ASoC: Dell IoT Gateway audio support

2016-12-19 Thread Shrirang Bagul
These patches add basic audio support on new Dell Edge IoT Gateways.
RT5660 codec is connected to SSP2 port on Intel Atom Baytrail E3815 SoC.
The machine driver is based on bytcr_rt5640. These devices have line-in and
line-out jacks with line-out mute enable gpio described in ACPI tables.

Shrirang Bagul (2):
  ASoC: rt5660: Add ACPI support
  ASoC: Intel: boards: Add Baytrail RT5660 machine driver

 sound/soc/codecs/rt5660.c |  26 ++
 sound/soc/intel/Kconfig   |  13 +
 sound/soc/intel/atom/sst/sst_acpi.c   |   2 +
 sound/soc/intel/boards/Makefile   |   2 +
 sound/soc/intel/boards/bytcr_rt5660.c | 573 ++
 5 files changed, 616 insertions(+)
 create mode 100644 sound/soc/intel/boards/bytcr_rt5660.c

-- 
2.9.3



[PATCH 1/2] ASoC: rt5660: Add ACPI support

2016-12-19 Thread Shrirang Bagul
On Dell IoT Gateways, RT5660 codec is available with ACPI ID 10EC3277.
Also, GPIO's are only available by index, so we register mappings to allow
machine drivers to access them by name.

Signed-off-by: Shrirang Bagul 
---
 sound/soc/codecs/rt5660.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/sound/soc/codecs/rt5660.c b/sound/soc/codecs/rt5660.c
index 76cf76a..c8bdeb3 100644
--- a/sound/soc/codecs/rt5660.c
+++ b/sound/soc/codecs/rt5660.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1245,10 +1246,31 @@ MODULE_DEVICE_TABLE(of, rt5660_of_match);
 
 static const struct acpi_device_id rt5660_acpi_match[] = {
{ "10EC5660", 0 },
+   { "10EC3277", 0 },
{ },
 };
 MODULE_DEVICE_TABLE(acpi, rt5660_acpi_match);
 
+static const struct acpi_gpio_params audio_wake_intr_gpio = { 0, 0, false };
+static const struct acpi_gpio_params lineout_mute_gpio = { 1, 0, true };
+
+static const struct acpi_gpio_mapping byt_rt5660_gpios[] = {
+   { "audio-wake-intr-gpios", _wake_intr_gpio, 1 },
+   { "lineout-mute-gpios", _mute_gpio, 1 },
+   { NULL },
+};
+
+static void rt5660_read_acpi_properties(struct rt5660_priv *rt5660,
+   struct device *dev)
+{
+   int ret;
+
+   ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev),
+   byt_rt5660_gpios);
+   if (ret)
+   dev_warn(dev, "Failed to add driver gpios\n");
+}
+
 static int rt5660_parse_dt(struct rt5660_priv *rt5660, struct device *dev)
 {
rt5660->pdata.in1_diff = device_property_read_bool(dev,
@@ -1288,6 +1310,10 @@ static int rt5660_i2c_probe(struct i2c_client *i2c,
rt5660->pdata = *pdata;
else if (i2c->dev.of_node)
rt5660_parse_dt(rt5660, >dev);
+   else if (ACPI_HANDLE(>dev))
+   rt5660_read_acpi_properties(rt5660, >dev);
+   else
+   return -EINVAL;
 
rt5660->regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(rt5660->regmap)) {
-- 
2.9.3



Re: [PATCH 2/3] iio: st_accel: Support sensor i2c probe using acpi

2016-11-28 Thread Shrirang Bagul
On Sun, 2016-11-27 at 11:14 +, Jonathan Cameron wrote:
> On 24/11/16 14:26, Linus Walleij wrote:
> > On Thu, Nov 24, 2016 at 6:33 AM, Shrirang Bagul
> > <shrirang.ba...@canonical.com> wrote:
> > 
> > > Add support to probe st_accel sensors on i2c bus using ACPI. Compatible
> > > strings are not avaialable on ACPI based systems.
> > > 
> > > Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
> > 
> > (...)
> > 
> > > +#ifdef CONFIG_ACPI
> > > +static const struct acpi_device_id st_accel_acpi_match[] = {
> > > +   {"SMO8A90", LNG2DM},
> > > +   { },
> > > +};
> > 
> > Why is ACPI only supporting one out of 14 devices?
> > 
> > Surely there are some out-of-tree ACPI platforms using one
> > or more of the others?
> > 
> > Apart from that it looks nice.
> 
> Applied to the togreg branch of iio.git and pushed out as testing
> for the autobuilders to play with it.
> 
> Anyone know where the ACPI names come from? Is there some big
> list somewhere to prevent clashes?
> 
> Jonathan
I'll take a look at the HW in our lab and send patches to identify more st_accel
sensors used mostly on Dell laptops.

Shrirang
> > 
> > Yours,
> > Linus Walleij
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 


Re: [PATCH 2/3] iio: st_accel: Support sensor i2c probe using acpi

2016-11-28 Thread Shrirang Bagul
On Sun, 2016-11-27 at 11:14 +, Jonathan Cameron wrote:
> On 24/11/16 14:26, Linus Walleij wrote:
> > On Thu, Nov 24, 2016 at 6:33 AM, Shrirang Bagul
> >  wrote:
> > 
> > > Add support to probe st_accel sensors on i2c bus using ACPI. Compatible
> > > strings are not avaialable on ACPI based systems.
> > > 
> > > Signed-off-by: Shrirang Bagul 
> > 
> > (...)
> > 
> > > +#ifdef CONFIG_ACPI
> > > +static const struct acpi_device_id st_accel_acpi_match[] = {
> > > +   {"SMO8A90", LNG2DM},
> > > +   { },
> > > +};
> > 
> > Why is ACPI only supporting one out of 14 devices?
> > 
> > Surely there are some out-of-tree ACPI platforms using one
> > or more of the others?
> > 
> > Apart from that it looks nice.
> 
> Applied to the togreg branch of iio.git and pushed out as testing
> for the autobuilders to play with it.
> 
> Anyone know where the ACPI names come from? Is there some big
> list somewhere to prevent clashes?
> 
> Jonathan
I'll take a look at the HW in our lab and send patches to identify more st_accel
sensors used mostly on Dell laptops.

Shrirang
> > 
> > Yours,
> > Linus Walleij
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 


Re: [PATCH 3/3] iio: st_pressure: Support i2c probe using acpi

2016-11-28 Thread Shrirang Bagul
On Sun, 2016-11-27 at 11:12 +, Jonathan Cameron wrote:
> On 24/11/16 14:28, Linus Walleij wrote:
> > On Thu, Nov 24, 2016 at 6:33 AM, Shrirang Bagul
> > <shrirang.ba...@canonical.com> wrote:
> > 
> > > Compatible strings are not available on ACPI based systems. This patch
> > > adds
> > > support to use DSDT information read from platform BIOS instead for
> > > probing
> > > st pressure sensors.
> > > 
> > > Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
> > 
> > (...)
> > > +#ifdef CONFIG_ACPI
> > > +static const struct acpi_device_id st_press_acpi_match[] = {
> > > +   {"SNO9210", LPS22HB},
> > > +   { },
> > > +};
> > 
> > Same comment. One sensor only supported by ACPI really?
> 
> As demonstrated by this one, they are often registered under effectively
> random names!
> Digging out those random names and associating them with a particular chip is
> always
> going to be a non trivial job.
> 
> Hence I'm happy to take these as they stand.  We can add more entries when we
> come
> across them.
> > 
> > Take a wider look.
Yes, I will.
> 
> Shirang has done a good job identifying this one and sending it upstream.
> Be nice Linus and don't try to get him to do all the hard work ;)
> 
> As such applied to the togreg branch of iio.git. Will be pushed out as testing
> for
> the autobuilders to play with it.
> 
> Note there will be some weeks before I push this out as togreg (given merge
> window
> is about to open) so plenty of time for others to take a look!
> 
> Thanks,
> 
> Jonathan
Thank you Jonathan. I'll follow-up on Linus's suggestion and try and identify
more of these sensors on some of the hardware we have in the lab. and try to add
support for some more devices.

Thanks,
Shrirang
> > 
> > Yours,
> > Linus Walleij
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 


Re: [PATCH 3/3] iio: st_pressure: Support i2c probe using acpi

2016-11-28 Thread Shrirang Bagul
On Sun, 2016-11-27 at 11:12 +, Jonathan Cameron wrote:
> On 24/11/16 14:28, Linus Walleij wrote:
> > On Thu, Nov 24, 2016 at 6:33 AM, Shrirang Bagul
> >  wrote:
> > 
> > > Compatible strings are not available on ACPI based systems. This patch
> > > adds
> > > support to use DSDT information read from platform BIOS instead for
> > > probing
> > > st pressure sensors.
> > > 
> > > Signed-off-by: Shrirang Bagul 
> > 
> > (...)
> > > +#ifdef CONFIG_ACPI
> > > +static const struct acpi_device_id st_press_acpi_match[] = {
> > > +   {"SNO9210", LPS22HB},
> > > +   { },
> > > +};
> > 
> > Same comment. One sensor only supported by ACPI really?
> 
> As demonstrated by this one, they are often registered under effectively
> random names!
> Digging out those random names and associating them with a particular chip is
> always
> going to be a non trivial job.
> 
> Hence I'm happy to take these as they stand.  We can add more entries when we
> come
> across them.
> > 
> > Take a wider look.
Yes, I will.
> 
> Shirang has done a good job identifying this one and sending it upstream.
> Be nice Linus and don't try to get him to do all the hard work ;)
> 
> As such applied to the togreg branch of iio.git. Will be pushed out as testing
> for
> the autobuilders to play with it.
> 
> Note there will be some weeks before I push this out as togreg (given merge
> window
> is about to open) so plenty of time for others to take a look!
> 
> Thanks,
> 
> Jonathan
Thank you Jonathan. I'll follow-up on Linus's suggestion and try and identify
more of these sensors on some of the hardware we have in the lab. and try to add
support for some more devices.

Thanks,
Shrirang
> > 
> > Yours,
> > Linus Walleij
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 


[PATCH] iio: humidity: Support acpi probe for hts211

2016-11-24 Thread Shrirang Bagul
Support driver probe by reading unique HID on systems based on ACPI instead
of DT compatible strings.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/iio/humidity/hts221_i2c.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/iio/humidity/hts221_i2c.c 
b/drivers/iio/humidity/hts221_i2c.c
index 367ecd5..8333c02 100644
--- a/drivers/iio/humidity/hts221_i2c.c
+++ b/drivers/iio/humidity/hts221_i2c.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "hts221.h"
@@ -83,6 +84,12 @@ static int hts221_i2c_probe(struct i2c_client *client,
return hts221_probe(iio_dev);
 }
 
+static const struct acpi_device_id hts221_acpi_match[] = {
+   {"SMO9100", 0},
+   { },
+};
+MODULE_DEVICE_TABLE(acpi, hts221_acpi_match);
+
 static const struct of_device_id hts221_i2c_of_match[] = {
{ .compatible = "st,hts221", },
{},
@@ -99,6 +106,7 @@ static struct i2c_driver hts221_driver = {
.driver = {
.name = "hts221_i2c",
.of_match_table = of_match_ptr(hts221_i2c_of_match),
+   .acpi_match_table = ACPI_PTR(hts221_acpi_match),
},
.probe = hts221_i2c_probe,
.id_table = hts221_i2c_id_table,
-- 
2.9.3



[PATCH] iio: humidity: Support acpi probe for hts211

2016-11-24 Thread Shrirang Bagul
Support driver probe by reading unique HID on systems based on ACPI instead
of DT compatible strings.

Signed-off-by: Shrirang Bagul 
---
 drivers/iio/humidity/hts221_i2c.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/iio/humidity/hts221_i2c.c 
b/drivers/iio/humidity/hts221_i2c.c
index 367ecd5..8333c02 100644
--- a/drivers/iio/humidity/hts221_i2c.c
+++ b/drivers/iio/humidity/hts221_i2c.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "hts221.h"
@@ -83,6 +84,12 @@ static int hts221_i2c_probe(struct i2c_client *client,
return hts221_probe(iio_dev);
 }
 
+static const struct acpi_device_id hts221_acpi_match[] = {
+   {"SMO9100", 0},
+   { },
+};
+MODULE_DEVICE_TABLE(acpi, hts221_acpi_match);
+
 static const struct of_device_id hts221_i2c_of_match[] = {
{ .compatible = "st,hts221", },
{},
@@ -99,6 +106,7 @@ static struct i2c_driver hts221_driver = {
.driver = {
.name = "hts221_i2c",
.of_match_table = of_match_ptr(hts221_i2c_of_match),
+   .acpi_match_table = ACPI_PTR(hts221_acpi_match),
},
.probe = hts221_i2c_probe,
.id_table = hts221_i2c_id_table,
-- 
2.9.3



[PATCH 0/3] iio: st_sensors: Support ACPI probe for st_sensors

2016-11-23 Thread Shrirang Bagul
Hi,

These patches are based on available work in iio git repository
(git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git) "testing"
branch.

Compatible strings don't exist on ACPI based systems. This patchset adds
probe support by reading ACPI unique identifiers from platform bios for
st_pressure and st_accel sensor drivers. Some of these sensors are present
on Dell IoT gateways.

Thanks,
Shrirang

Shrirang Bagul (3):
  iio: st_sensors: match sensors using ACPI handle
  iio: st_accel: Support sensor i2c probe using acpi
  iio: st_pressure: Support i2c probe using acpi

 drivers/iio/accel/st_accel.h   | 18 +++
 drivers/iio/accel/st_accel_i2c.c   | 73 +-
 drivers/iio/common/st_sensors/st_sensors_i2c.c | 20 +++
 drivers/iio/pressure/st_pressure.h |  8 +++
 drivers/iio/pressure/st_pressure_i2c.c | 51 +-
 include/linux/iio/common/st_sensors_i2c.h  |  9 
 6 files changed, 142 insertions(+), 37 deletions(-)

-- 
2.9.3



[PATCH 0/3] iio: st_sensors: Support ACPI probe for st_sensors

2016-11-23 Thread Shrirang Bagul
Hi,

These patches are based on available work in iio git repository
(git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git) "testing"
branch.

Compatible strings don't exist on ACPI based systems. This patchset adds
probe support by reading ACPI unique identifiers from platform bios for
st_pressure and st_accel sensor drivers. Some of these sensors are present
on Dell IoT gateways.

Thanks,
Shrirang

Shrirang Bagul (3):
  iio: st_sensors: match sensors using ACPI handle
  iio: st_accel: Support sensor i2c probe using acpi
  iio: st_pressure: Support i2c probe using acpi

 drivers/iio/accel/st_accel.h   | 18 +++
 drivers/iio/accel/st_accel_i2c.c   | 73 +-
 drivers/iio/common/st_sensors/st_sensors_i2c.c | 20 +++
 drivers/iio/pressure/st_pressure.h |  8 +++
 drivers/iio/pressure/st_pressure_i2c.c | 51 +-
 include/linux/iio/common/st_sensors_i2c.h  |  9 
 6 files changed, 142 insertions(+), 37 deletions(-)

-- 
2.9.3



[PATCH 2/3] iio: st_accel: Support sensor i2c probe using acpi

2016-11-23 Thread Shrirang Bagul
Add support to probe st_accel sensors on i2c bus using ACPI. Compatible
strings are not avaialable on ACPI based systems.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/iio/accel/st_accel.h | 18 ++
 drivers/iio/accel/st_accel_i2c.c | 73 +++-
 2 files changed, 67 insertions(+), 24 deletions(-)

diff --git a/drivers/iio/accel/st_accel.h b/drivers/iio/accel/st_accel.h
index 7c23168..3ad44ce 100644
--- a/drivers/iio/accel/st_accel.h
+++ b/drivers/iio/accel/st_accel.h
@@ -14,6 +14,24 @@
 #include 
 #include 
 
+enum st_accel_type {
+   LSM303DLH,
+   LSM303DLHC,
+   LIS3DH,
+   LSM330D,
+   LSM330DL,
+   LSM330DLC,
+   LIS331DLH,
+   LSM303DL,
+   LSM303DLM,
+   LSM330,
+   LSM303AGR,
+   LIS2DH12,
+   LIS3L02DQ,
+   LNG2DM,
+   ST_ACCEL_MAX,
+};
+
 #define H3LIS331DL_DRIVER_NAME "h3lis331dl_accel"
 #define LIS3LV02DL_ACCEL_DEV_NAME  "lis3lv02dl_accel"
 #define LSM303DLHC_ACCEL_DEV_NAME  "lsm303dlhc_accel"
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index c0f8867..2840649 100644
--- a/drivers/iio/accel/st_accel_i2c.c
+++ b/drivers/iio/accel/st_accel_i2c.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -95,25 +96,67 @@ MODULE_DEVICE_TABLE(of, st_accel_of_match);
 #define st_accel_of_match NULL
 #endif
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id st_accel_acpi_match[] = {
+   {"SMO8A90", LNG2DM},
+   { },
+};
+MODULE_DEVICE_TABLE(acpi, st_accel_acpi_match);
+#else
+#define st_accel_acpi_match NULL
+#endif
+
+static const struct i2c_device_id st_accel_id_table[] = {
+   { LSM303DLH_ACCEL_DEV_NAME, LSM303DLH },
+   { LSM303DLHC_ACCEL_DEV_NAME, LSM303DLHC },
+   { LIS3DH_ACCEL_DEV_NAME, LIS3DH },
+   { LSM330D_ACCEL_DEV_NAME, LSM330D },
+   { LSM330DL_ACCEL_DEV_NAME, LSM330DL },
+   { LSM330DLC_ACCEL_DEV_NAME, LSM330DLC },
+   { LIS331DLH_ACCEL_DEV_NAME, LIS331DLH },
+   { LSM303DL_ACCEL_DEV_NAME, LSM303DL },
+   { LSM303DLM_ACCEL_DEV_NAME, LSM303DLM },
+   { LSM330_ACCEL_DEV_NAME, LSM330 },
+   { LSM303AGR_ACCEL_DEV_NAME, LSM303AGR },
+   { LIS2DH12_ACCEL_DEV_NAME, LIS2DH12 },
+   { LIS3L02DQ_ACCEL_DEV_NAME, LIS3L02DQ },
+   { LNG2DM_ACCEL_DEV_NAME, LNG2DM },
+   {},
+};
+MODULE_DEVICE_TABLE(i2c, st_accel_id_table);
+
 static int st_accel_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
struct iio_dev *indio_dev;
struct st_sensor_data *adata;
-   int err;
+   int ret;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*adata));
if (!indio_dev)
return -ENOMEM;
 
adata = iio_priv(indio_dev);
-   st_sensors_of_i2c_probe(client, st_accel_of_match);
+
+   if (client->dev.of_node) {
+   st_sensors_of_i2c_probe(client, st_accel_of_match);
+   } else if (ACPI_HANDLE(>dev)) {
+   ret = st_sensors_match_acpi_device(>dev);
+   if ((ret < 0) || (ret >= ST_ACCEL_MAX))
+   return -ENODEV;
+
+   strncpy(client->name, st_accel_id_table[ret].name,
+   sizeof(client->name));
+   client->name[sizeof(client->name) - 1] = '\0';
+   } else if (!id)
+   return -ENODEV;
+
 
st_sensors_i2c_configure(indio_dev, client, adata);
 
-   err = st_accel_common_probe(indio_dev);
-   if (err < 0)
-   return err;
+   ret = st_accel_common_probe(indio_dev);
+   if (ret < 0)
+   return ret;
 
return 0;
 }
@@ -125,29 +168,11 @@ static int st_accel_i2c_remove(struct i2c_client *client)
return 0;
 }
 
-static const struct i2c_device_id st_accel_id_table[] = {
-   { LSM303DLH_ACCEL_DEV_NAME },
-   { LSM303DLHC_ACCEL_DEV_NAME },
-   { LIS3DH_ACCEL_DEV_NAME },
-   { LSM330D_ACCEL_DEV_NAME },
-   { LSM330DL_ACCEL_DEV_NAME },
-   { LSM330DLC_ACCEL_DEV_NAME },
-   { LIS331DLH_ACCEL_DEV_NAME },
-   { LSM303DL_ACCEL_DEV_NAME },
-   { LSM303DLM_ACCEL_DEV_NAME },
-   { LSM330_ACCEL_DEV_NAME },
-   { LSM303AGR_ACCEL_DEV_NAME },
-   { LIS2DH12_ACCEL_DEV_NAME },
-   { LIS3L02DQ_ACCEL_DEV_NAME },
-   { LNG2DM_ACCEL_DEV_NAME },
-   {},
-};
-MODULE_DEVICE_TABLE(i2c, st_accel_id_table);
-
 static struct i2c_driver st_accel_driver = {
.driver = {
.name = "st-accel-i2c",
.of_match_table = of_match_ptr(st_accel_of_match),
+   .acpi_match_table = ACPI_PTR(st_accel_acpi_match),
},
.probe = st_accel_i2c_probe,
.remove = st_accel_i2c_remove,
-- 
2.9.3



[PATCH 2/3] iio: st_accel: Support sensor i2c probe using acpi

2016-11-23 Thread Shrirang Bagul
Add support to probe st_accel sensors on i2c bus using ACPI. Compatible
strings are not avaialable on ACPI based systems.

Signed-off-by: Shrirang Bagul 
---
 drivers/iio/accel/st_accel.h | 18 ++
 drivers/iio/accel/st_accel_i2c.c | 73 +++-
 2 files changed, 67 insertions(+), 24 deletions(-)

diff --git a/drivers/iio/accel/st_accel.h b/drivers/iio/accel/st_accel.h
index 7c23168..3ad44ce 100644
--- a/drivers/iio/accel/st_accel.h
+++ b/drivers/iio/accel/st_accel.h
@@ -14,6 +14,24 @@
 #include 
 #include 
 
+enum st_accel_type {
+   LSM303DLH,
+   LSM303DLHC,
+   LIS3DH,
+   LSM330D,
+   LSM330DL,
+   LSM330DLC,
+   LIS331DLH,
+   LSM303DL,
+   LSM303DLM,
+   LSM330,
+   LSM303AGR,
+   LIS2DH12,
+   LIS3L02DQ,
+   LNG2DM,
+   ST_ACCEL_MAX,
+};
+
 #define H3LIS331DL_DRIVER_NAME "h3lis331dl_accel"
 #define LIS3LV02DL_ACCEL_DEV_NAME  "lis3lv02dl_accel"
 #define LSM303DLHC_ACCEL_DEV_NAME  "lsm303dlhc_accel"
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index c0f8867..2840649 100644
--- a/drivers/iio/accel/st_accel_i2c.c
+++ b/drivers/iio/accel/st_accel_i2c.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -95,25 +96,67 @@ MODULE_DEVICE_TABLE(of, st_accel_of_match);
 #define st_accel_of_match NULL
 #endif
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id st_accel_acpi_match[] = {
+   {"SMO8A90", LNG2DM},
+   { },
+};
+MODULE_DEVICE_TABLE(acpi, st_accel_acpi_match);
+#else
+#define st_accel_acpi_match NULL
+#endif
+
+static const struct i2c_device_id st_accel_id_table[] = {
+   { LSM303DLH_ACCEL_DEV_NAME, LSM303DLH },
+   { LSM303DLHC_ACCEL_DEV_NAME, LSM303DLHC },
+   { LIS3DH_ACCEL_DEV_NAME, LIS3DH },
+   { LSM330D_ACCEL_DEV_NAME, LSM330D },
+   { LSM330DL_ACCEL_DEV_NAME, LSM330DL },
+   { LSM330DLC_ACCEL_DEV_NAME, LSM330DLC },
+   { LIS331DLH_ACCEL_DEV_NAME, LIS331DLH },
+   { LSM303DL_ACCEL_DEV_NAME, LSM303DL },
+   { LSM303DLM_ACCEL_DEV_NAME, LSM303DLM },
+   { LSM330_ACCEL_DEV_NAME, LSM330 },
+   { LSM303AGR_ACCEL_DEV_NAME, LSM303AGR },
+   { LIS2DH12_ACCEL_DEV_NAME, LIS2DH12 },
+   { LIS3L02DQ_ACCEL_DEV_NAME, LIS3L02DQ },
+   { LNG2DM_ACCEL_DEV_NAME, LNG2DM },
+   {},
+};
+MODULE_DEVICE_TABLE(i2c, st_accel_id_table);
+
 static int st_accel_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
struct iio_dev *indio_dev;
struct st_sensor_data *adata;
-   int err;
+   int ret;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*adata));
if (!indio_dev)
return -ENOMEM;
 
adata = iio_priv(indio_dev);
-   st_sensors_of_i2c_probe(client, st_accel_of_match);
+
+   if (client->dev.of_node) {
+   st_sensors_of_i2c_probe(client, st_accel_of_match);
+   } else if (ACPI_HANDLE(>dev)) {
+   ret = st_sensors_match_acpi_device(>dev);
+   if ((ret < 0) || (ret >= ST_ACCEL_MAX))
+   return -ENODEV;
+
+   strncpy(client->name, st_accel_id_table[ret].name,
+   sizeof(client->name));
+   client->name[sizeof(client->name) - 1] = '\0';
+   } else if (!id)
+   return -ENODEV;
+
 
st_sensors_i2c_configure(indio_dev, client, adata);
 
-   err = st_accel_common_probe(indio_dev);
-   if (err < 0)
-   return err;
+   ret = st_accel_common_probe(indio_dev);
+   if (ret < 0)
+   return ret;
 
return 0;
 }
@@ -125,29 +168,11 @@ static int st_accel_i2c_remove(struct i2c_client *client)
return 0;
 }
 
-static const struct i2c_device_id st_accel_id_table[] = {
-   { LSM303DLH_ACCEL_DEV_NAME },
-   { LSM303DLHC_ACCEL_DEV_NAME },
-   { LIS3DH_ACCEL_DEV_NAME },
-   { LSM330D_ACCEL_DEV_NAME },
-   { LSM330DL_ACCEL_DEV_NAME },
-   { LSM330DLC_ACCEL_DEV_NAME },
-   { LIS331DLH_ACCEL_DEV_NAME },
-   { LSM303DL_ACCEL_DEV_NAME },
-   { LSM303DLM_ACCEL_DEV_NAME },
-   { LSM330_ACCEL_DEV_NAME },
-   { LSM303AGR_ACCEL_DEV_NAME },
-   { LIS2DH12_ACCEL_DEV_NAME },
-   { LIS3L02DQ_ACCEL_DEV_NAME },
-   { LNG2DM_ACCEL_DEV_NAME },
-   {},
-};
-MODULE_DEVICE_TABLE(i2c, st_accel_id_table);
-
 static struct i2c_driver st_accel_driver = {
.driver = {
.name = "st-accel-i2c",
.of_match_table = of_match_ptr(st_accel_of_match),
+   .acpi_match_table = ACPI_PTR(st_accel_acpi_match),
},
.probe = st_accel_i2c_probe,
.remove = st_accel_i2c_remove,
-- 
2.9.3



[PATCH 1/3] iio: st_sensors: match sensors using ACPI handle

2016-11-23 Thread Shrirang Bagul
Add support to match st sensors using information passed from ACPI DST
tables.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/iio/common/st_sensors/st_sensors_i2c.c | 20 
 include/linux/iio/common/st_sensors_i2c.h  |  9 +
 2 files changed, 29 insertions(+)

diff --git a/drivers/iio/common/st_sensors/st_sensors_i2c.c 
b/drivers/iio/common/st_sensors/st_sensors_i2c.c
index b43aa36..c83df4d 100644
--- a/drivers/iio/common/st_sensors/st_sensors_i2c.c
+++ b/drivers/iio/common/st_sensors/st_sensors_i2c.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -107,6 +108,25 @@ void st_sensors_of_i2c_probe(struct i2c_client *client,
 EXPORT_SYMBOL(st_sensors_of_i2c_probe);
 #endif
 
+#ifdef CONFIG_ACPI
+int st_sensors_match_acpi_device(struct device *dev)
+{
+   const struct acpi_device_id *acpi_id;
+   kernel_ulong_t driver_data = 0;
+
+   if (ACPI_HANDLE(dev)) {
+   acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
+   if (!acpi_id) {
+   dev_err(dev, "No driver data\n");
+   return -EINVAL;
+   }
+   driver_data = acpi_id->driver_data;
+   }
+   return driver_data;
+}
+EXPORT_SYMBOL(st_sensors_match_acpi_device);
+#endif
+
 MODULE_AUTHOR("Denis Ciocca <denis.cio...@st.com>");
 MODULE_DESCRIPTION("STMicroelectronics ST-sensors i2c driver");
 MODULE_LICENSE("GPL v2");
diff --git a/include/linux/iio/common/st_sensors_i2c.h 
b/include/linux/iio/common/st_sensors_i2c.h
index 1796af0..254de3c 100644
--- a/include/linux/iio/common/st_sensors_i2c.h
+++ b/include/linux/iio/common/st_sensors_i2c.h
@@ -28,4 +28,13 @@ static inline void st_sensors_of_i2c_probe(struct i2c_client 
*client,
 }
 #endif
 
+#ifdef CONFIG_ACPI
+int st_sensors_match_acpi_device(struct device *dev);
+#else
+static inline int st_sensors_match_acpi_device(struct device *dev)
+{
+   return -ENODEV;
+}
+#endif
+
 #endif /* ST_SENSORS_I2C_H */
-- 
2.9.3



[PATCH 3/3] iio: st_pressure: Support i2c probe using acpi

2016-11-23 Thread Shrirang Bagul
Compatible strings are not available on ACPI based systems. This patch adds
support to use DSDT information read from platform BIOS instead for probing
st pressure sensors.

Signed-off-by: Shrirang Bagul <shrirang.ba...@canonical.com>
---
 drivers/iio/pressure/st_pressure.h |  8 ++
 drivers/iio/pressure/st_pressure_i2c.c | 51 +-
 2 files changed, 46 insertions(+), 13 deletions(-)

diff --git a/drivers/iio/pressure/st_pressure.h 
b/drivers/iio/pressure/st_pressure.h
index 903a21e..7d99593 100644
--- a/drivers/iio/pressure/st_pressure.h
+++ b/drivers/iio/pressure/st_pressure.h
@@ -14,6 +14,14 @@
 #include 
 #include 
 
+enum st_press_type {
+   LPS001WP,
+   LPS25H,
+   LPS331AP,
+   LPS22HB,
+   ST_PRESS_MAX,
+};
+
 #define LPS001WP_PRESS_DEV_NAME"lps001wp"
 #define LPS25H_PRESS_DEV_NAME  "lps25h"
 #define LPS331AP_PRESS_DEV_NAME"lps331ap"
diff --git a/drivers/iio/pressure/st_pressure_i2c.c 
b/drivers/iio/pressure/st_pressure_i2c.c
index ed18701..17417a4 100644
--- a/drivers/iio/pressure/st_pressure_i2c.c
+++ b/drivers/iio/pressure/st_pressure_i2c.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -43,25 +44,56 @@ MODULE_DEVICE_TABLE(of, st_press_of_match);
 #define st_press_of_match NULL
 #endif
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id st_press_acpi_match[] = {
+   {"SNO9210", LPS22HB},
+   { },
+};
+MODULE_DEVICE_TABLE(acpi, st_press_acpi_match);
+#else
+#define st_press_acpi_match NULL
+#endif
+
+static const struct i2c_device_id st_press_id_table[] = {
+   { LPS001WP_PRESS_DEV_NAME, LPS001WP },
+   { LPS25H_PRESS_DEV_NAME,  LPS25H },
+   { LPS331AP_PRESS_DEV_NAME, LPS331AP },
+   { LPS22HB_PRESS_DEV_NAME, LPS22HB },
+   {},
+};
+MODULE_DEVICE_TABLE(i2c, st_press_id_table);
+
 static int st_press_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
struct iio_dev *indio_dev;
struct st_sensor_data *press_data;
-   int err;
+   int ret;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*press_data));
if (!indio_dev)
return -ENOMEM;
 
press_data = iio_priv(indio_dev);
-   st_sensors_of_i2c_probe(client, st_press_of_match);
+
+   if (client->dev.of_node) {
+   st_sensors_of_i2c_probe(client, st_press_of_match);
+   } else if (ACPI_HANDLE(>dev)) {
+   ret = st_sensors_match_acpi_device(>dev);
+   if ((ret < 0) || (ret >= ST_PRESS_MAX))
+   return -ENODEV;
+
+   strncpy(client->name, st_press_id_table[ret].name,
+   sizeof(client->name));
+   client->name[sizeof(client->name) - 1] = '\0';
+   } else if (!id)
+   return -ENODEV;
 
st_sensors_i2c_configure(indio_dev, client, press_data);
 
-   err = st_press_common_probe(indio_dev);
-   if (err < 0)
-   return err;
+   ret = st_press_common_probe(indio_dev);
+   if (ret < 0)
+   return ret;
 
return 0;
 }
@@ -73,18 +105,11 @@ static int st_press_i2c_remove(struct i2c_client *client)
return 0;
 }
 
-static const struct i2c_device_id st_press_id_table[] = {
-   { LPS001WP_PRESS_DEV_NAME },
-   { LPS25H_PRESS_DEV_NAME },
-   { LPS331AP_PRESS_DEV_NAME },
-   {},
-};
-MODULE_DEVICE_TABLE(i2c, st_press_id_table);
-
 static struct i2c_driver st_press_driver = {
.driver = {
.name = "st-press-i2c",
.of_match_table = of_match_ptr(st_press_of_match),
+   .acpi_match_table = ACPI_PTR(st_press_acpi_match),
},
.probe = st_press_i2c_probe,
.remove = st_press_i2c_remove,
-- 
2.9.3



[PATCH 1/3] iio: st_sensors: match sensors using ACPI handle

2016-11-23 Thread Shrirang Bagul
Add support to match st sensors using information passed from ACPI DST
tables.

Signed-off-by: Shrirang Bagul 
---
 drivers/iio/common/st_sensors/st_sensors_i2c.c | 20 
 include/linux/iio/common/st_sensors_i2c.h  |  9 +
 2 files changed, 29 insertions(+)

diff --git a/drivers/iio/common/st_sensors/st_sensors_i2c.c 
b/drivers/iio/common/st_sensors/st_sensors_i2c.c
index b43aa36..c83df4d 100644
--- a/drivers/iio/common/st_sensors/st_sensors_i2c.c
+++ b/drivers/iio/common/st_sensors/st_sensors_i2c.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -107,6 +108,25 @@ void st_sensors_of_i2c_probe(struct i2c_client *client,
 EXPORT_SYMBOL(st_sensors_of_i2c_probe);
 #endif
 
+#ifdef CONFIG_ACPI
+int st_sensors_match_acpi_device(struct device *dev)
+{
+   const struct acpi_device_id *acpi_id;
+   kernel_ulong_t driver_data = 0;
+
+   if (ACPI_HANDLE(dev)) {
+   acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
+   if (!acpi_id) {
+   dev_err(dev, "No driver data\n");
+   return -EINVAL;
+   }
+   driver_data = acpi_id->driver_data;
+   }
+   return driver_data;
+}
+EXPORT_SYMBOL(st_sensors_match_acpi_device);
+#endif
+
 MODULE_AUTHOR("Denis Ciocca ");
 MODULE_DESCRIPTION("STMicroelectronics ST-sensors i2c driver");
 MODULE_LICENSE("GPL v2");
diff --git a/include/linux/iio/common/st_sensors_i2c.h 
b/include/linux/iio/common/st_sensors_i2c.h
index 1796af0..254de3c 100644
--- a/include/linux/iio/common/st_sensors_i2c.h
+++ b/include/linux/iio/common/st_sensors_i2c.h
@@ -28,4 +28,13 @@ static inline void st_sensors_of_i2c_probe(struct i2c_client 
*client,
 }
 #endif
 
+#ifdef CONFIG_ACPI
+int st_sensors_match_acpi_device(struct device *dev);
+#else
+static inline int st_sensors_match_acpi_device(struct device *dev)
+{
+   return -ENODEV;
+}
+#endif
+
 #endif /* ST_SENSORS_I2C_H */
-- 
2.9.3



[PATCH 3/3] iio: st_pressure: Support i2c probe using acpi

2016-11-23 Thread Shrirang Bagul
Compatible strings are not available on ACPI based systems. This patch adds
support to use DSDT information read from platform BIOS instead for probing
st pressure sensors.

Signed-off-by: Shrirang Bagul 
---
 drivers/iio/pressure/st_pressure.h |  8 ++
 drivers/iio/pressure/st_pressure_i2c.c | 51 +-
 2 files changed, 46 insertions(+), 13 deletions(-)

diff --git a/drivers/iio/pressure/st_pressure.h 
b/drivers/iio/pressure/st_pressure.h
index 903a21e..7d99593 100644
--- a/drivers/iio/pressure/st_pressure.h
+++ b/drivers/iio/pressure/st_pressure.h
@@ -14,6 +14,14 @@
 #include 
 #include 
 
+enum st_press_type {
+   LPS001WP,
+   LPS25H,
+   LPS331AP,
+   LPS22HB,
+   ST_PRESS_MAX,
+};
+
 #define LPS001WP_PRESS_DEV_NAME"lps001wp"
 #define LPS25H_PRESS_DEV_NAME  "lps25h"
 #define LPS331AP_PRESS_DEV_NAME"lps331ap"
diff --git a/drivers/iio/pressure/st_pressure_i2c.c 
b/drivers/iio/pressure/st_pressure_i2c.c
index ed18701..17417a4 100644
--- a/drivers/iio/pressure/st_pressure_i2c.c
+++ b/drivers/iio/pressure/st_pressure_i2c.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -43,25 +44,56 @@ MODULE_DEVICE_TABLE(of, st_press_of_match);
 #define st_press_of_match NULL
 #endif
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id st_press_acpi_match[] = {
+   {"SNO9210", LPS22HB},
+   { },
+};
+MODULE_DEVICE_TABLE(acpi, st_press_acpi_match);
+#else
+#define st_press_acpi_match NULL
+#endif
+
+static const struct i2c_device_id st_press_id_table[] = {
+   { LPS001WP_PRESS_DEV_NAME, LPS001WP },
+   { LPS25H_PRESS_DEV_NAME,  LPS25H },
+   { LPS331AP_PRESS_DEV_NAME, LPS331AP },
+   { LPS22HB_PRESS_DEV_NAME, LPS22HB },
+   {},
+};
+MODULE_DEVICE_TABLE(i2c, st_press_id_table);
+
 static int st_press_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
struct iio_dev *indio_dev;
struct st_sensor_data *press_data;
-   int err;
+   int ret;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*press_data));
if (!indio_dev)
return -ENOMEM;
 
press_data = iio_priv(indio_dev);
-   st_sensors_of_i2c_probe(client, st_press_of_match);
+
+   if (client->dev.of_node) {
+   st_sensors_of_i2c_probe(client, st_press_of_match);
+   } else if (ACPI_HANDLE(>dev)) {
+   ret = st_sensors_match_acpi_device(>dev);
+   if ((ret < 0) || (ret >= ST_PRESS_MAX))
+   return -ENODEV;
+
+   strncpy(client->name, st_press_id_table[ret].name,
+   sizeof(client->name));
+   client->name[sizeof(client->name) - 1] = '\0';
+   } else if (!id)
+   return -ENODEV;
 
st_sensors_i2c_configure(indio_dev, client, press_data);
 
-   err = st_press_common_probe(indio_dev);
-   if (err < 0)
-   return err;
+   ret = st_press_common_probe(indio_dev);
+   if (ret < 0)
+   return ret;
 
return 0;
 }
@@ -73,18 +105,11 @@ static int st_press_i2c_remove(struct i2c_client *client)
return 0;
 }
 
-static const struct i2c_device_id st_press_id_table[] = {
-   { LPS001WP_PRESS_DEV_NAME },
-   { LPS25H_PRESS_DEV_NAME },
-   { LPS331AP_PRESS_DEV_NAME },
-   {},
-};
-MODULE_DEVICE_TABLE(i2c, st_press_id_table);
-
 static struct i2c_driver st_press_driver = {
.driver = {
.name = "st-press-i2c",
.of_match_table = of_match_ptr(st_press_of_match),
+   .acpi_match_table = ACPI_PTR(st_press_acpi_match),
},
.probe = st_press_i2c_probe,
.remove = st_press_i2c_remove,
-- 
2.9.3