from:"ilkka.koskinen"

RE: [PATCH] rtc-twl: Switch to using threaded irq

2011-05-05 Thread ilkka.koskinen


Hi,

Tony and John: What would be the appropriate path for this patch?

Cheers, Ilkka

On Apr 13, 2011 Krishnamoorthy, Balaji T  wrote:
On Wed, Mar 16, 2011 at 9:37 PM, Ilkka Koskinen
ilkka.koski...@nokia.com wrote:

 The driver is accessing to i2c bus in interrupt handler.
 Therefore, it should use threaded irq.

Acked-by: Balaji T K balaj...@ti.com


 Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
 ---
  drivers/rtc/rtc-twl.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
 index ed1b868..2715b96 100644
 --- a/drivers/rtc/rtc-twl.c
 +++ b/drivers/rtc/rtc-twl.c
 @@ -475,7 +475,7 @@ static int __devinit twl_rtc_probe(struct 
 platform_device *pdev)
if (ret  0)
goto out1;

 -   ret = request_irq(irq, twl_rtc_interrupt,
 +   ret = request_threaded_irq(irq, NULL, twl_rtc_interrupt,
IRQF_TRIGGER_RISING,
dev_name(rtc-dev), rtc);
if (ret  0) {
 --
 1.7.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone

2010-02-22 Thread ilkka.koskinen

 

From: Nurkkala Eero.An (EXT-Offcode/Oulu) 
Sent: 19 February, 2010 21:04

 Oops, I seemed to copy Q1.14 instead of Q14.1, but isn't it 
still the same.
 When I added some debug messages it still seemed to be corret.
 
 Lowest number (-32768) is represented with 16th bit '1' and 
the rest are
 zeros, right? That is 0x8000.
 -1 has all the bits set (0x) and 0 has all the bit 
cleared (0x).
 Highest positive value has 16th bit cleared and the rest set 
(0x7fff).
 
 Or did I interpret something wrong?
 
 Cheers, Ilkka

I guess it's just fine, but let's see. Maybe I was lost in the 
Q1.14: m + n + 1 ~
binary: [sign bit, (m), (n)] where m is the integer portion, 0 
or 1, n is 14 bits..
so  if your input was [-32768... 32767] - [-2,2] then, for example,
-32768 is in hex: 0x8000, but the 2nd most significant bit is 
zero, which means
the integer portion (m) is not 1, which makes me doubt the 
gain -32768 is
actually -1 (or 0), not -2. But then, as it's a two's 
complement, it maybe just correct.

So most likely it's just fine; I just had a thinko.

Ok, now I got your point :) However, as far as I can understand
the Q notation right, it basically defines how to interpret the 
value. That is, where is the decimal point. Thus, I would say that
the code should work fine and based on quick tests, the gain control
seems to behave ok too.

Cheers, Ilkka--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone

2010-02-19 Thread ilkka.koskinen

 

From: Nurkkala Eero.An (EXT-Offcode/Oulu) 
Sent: 19 February, 2010 14:58

 I'm a bit confused. What do you mean by that?
 
 AFAICS, Q1.14 defines values [-16384.0, +16383.5], which are 
mapped in the
 driver to integers [-32768, 32767], right? Moreover, those 
Q1.14 values in
 registers are mapped to [-2, 2] in HW. So is there a problem 
somewhere?
 
 Cheers, Ilkka

No, don't get me wrong, not saying there's a problem with the 
positive gains,
Q1.14: its range is [-16384.0, +16383.5] = [0x8000, 0x8001 … 0x,
0x, 0x0001 … 0x7FFE, 0x7FFF]
if I read this correctly, your min is 0x, but the real min maybe
0x8000? To be honest, it may be just me interpreting that incorrectly..
...as if the value is in two's complement, it goes the opposite:
http://en.wikipedia.org/wiki/Two%27s_complement , see:
1 0 0 0 0 0 0 0 = −128
1 1 1 1 1 1 1 1 = −1
what do you think? maybe try it out to see the truth..

Oops, I seemed to copy Q1.14 instead of Q14.1, but isn't it still the same.
When I added some debug messages it still seemed to be corret.

Lowest number (-32768) is represented with 16th bit '1' and the rest are
zeros, right? That is 0x8000.
-1 has all the bits set (0x) and 0 has all the bit cleared (0x).
Highest positive value has 16th bit cleared and the rest set (0x7fff).

Or did I interpret something wrong?

Cheers, Ilkka

RE: [PATCHv2 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone

2010-02-18 Thread ilkka.koskinen

 

From: Ujfalusi Peter (Nokia-D/Tampere) 
Sent: 18 February, 2010 10:15

Hello,

Looks good, but I have one comment, you can consider if you like it...

...

 +static int omap_mcbsp2_st_set_mode(struct snd_kcontrol *kcontrol,
 +struct snd_ctl_elem_value *ucontrol)
 +{
 +u8 value = ucontrol-value.integer.value[0];
 +
 +if (value == omap_st_is_enabled(1))
 +return 0;
 +
 +if (value)
 +omap_st_enable(1);
 +else
 +omap_st_disable(1);
 +
 +return 1;
 +}
 +
 +static int omap_mcbsp2_st_get_mode(struct snd_kcontrol *kcontrol,
 +struct snd_ctl_elem_value *ucontrol)
 +{
 +ucontrol-value.integer.value[0] = omap_st_is_enabled(1);
 +return 0;
 +}
 +
 +static int omap_mcbsp3_st_set_mode(struct snd_kcontrol *kcontrol,
 +struct snd_ctl_elem_value *ucontrol)
 +{
 +u8 value = ucontrol-value.integer.value[0];
 +
 +if (value == omap_st_is_enabled(2))
 +return 0;
 +
 +if (value)
 +omap_st_enable(2);
 +else
 +omap_st_disable(2);
 +
 +return 1;
 +}
 +
 +static int omap_mcbsp3_st_get_mode(struct snd_kcontrol *kcontrol,
 +struct snd_ctl_elem_value *ucontrol)
 +{
 +
 +ucontrol-value.integer.value[0] = omap_st_is_enabled(2);
 +return 0;
 +}

Instead of having these two set of function, I would have only one:

static int omap_mcbsp_st_put_mode(struct snd_kcontrol *kcontrol,
   struct 
snd_ctl_elem_value *ucontrol)
{
   struct soc_mixer_control *mc =
   (struct soc_mixer_control 
*)kcontrol-private_value;
   u8 value = ucontrol-value.integer.value[0];

   if (value == omap_st_is_enabled(mc-reg))
   return 0;

   if (value)
   omap_st_enable(mc-reg);
   else
   omap_st_disable(mc-reg);

   return 1;
}

static int omap_mcbsp_st_get_mode(struct snd_kcontrol *kcontrol,
   struct 
snd_ctl_elem_value *ucontrol)
{
   struct soc_mixer_control *mc =
   (struct soc_mixer_control 
*)kcontrol-private_value;

   ucontrol-value.integer.value[0] = omap_st_is_enabled(mc-reg);

   return 0;
}

Than

Makes sense - I'll change it.

Cheers, Ilkka


 +static const struct snd_kcontrol_new omap_mcbsp2_st_controls[] = {
 +SOC_SINGLE_EXT(McBSP2 Sidetone Switch, 0, 0, 1, 0,
 +omap_mcbsp2_st_get_mode, 
omap_mcbsp2_st_set_mode),

   SOC_SINGLE_EXT(McBSP2 Sidetone Switch, 1, 0, 1, 0,
   omap_mcbsp_st_get_mode, omap_mcbsp_st_put_mode),

 +OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP2 Sidetone Channel 
0 Volume,
 +  -32768, 32767,
 +  omap_mcbsp2_get_st_ch0_volume,
 +  omap_mcbsp2_set_st_ch0_volume),
 +OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP2 Sidetone Channel 
1 Volume,
 +  -32768, 32767,
 +  omap_mcbsp2_get_st_ch1_volume,
 +  omap_mcbsp2_set_st_ch1_volume),
 +};
 +
 +static const struct snd_kcontrol_new omap_mcbsp3_st_controls[] = {
 +SOC_SINGLE_EXT(McBSP3 Sidetone Switch, 0, 0, 1, 0,
 +omap_mcbsp3_st_get_mode, 
omap_mcbsp3_st_set_mode),

   SOC_SINGLE_EXT(McBSP3 Sidetone Switch, 2, 0, 1, 0,
   omap_mcbsp_st_get_mode, omap_mcbsp_st_put_mode),

 +OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP3 Sidetone Channel 
0 Volume,
 +  -32768, 32767,
 +  omap_mcbsp3_get_st_ch0_volume,
 +  omap_mcbsp3_set_st_ch0_volume),
 +OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP3 Sidetone Channel 
1 Volume,
 +  -32768, 32767,
 +  omap_mcbsp3_get_st_ch1_volume,
 +  omap_mcbsp3_set_st_ch1_volume),
 +};
 +
 +int omap_mcbsp_st_add_controls(struct snd_soc_codec *codec, 
int mcbsp_id)
 +{
 +if (!cpu_is_omap34xx())
 +return -ENODEV;
 +
 +switch (mcbsp_id) {
 +case 2: /* McBSP 2 */
 +return snd_soc_add_controls(codec, 
omap_mcbsp2_st_controls,
 +
ARRAY_SIZE(omap_mcbsp2_st_controls));
 +case 3: /* McBSP 3 */
 +return snd_soc_add_controls(codec, 
omap_mcbsp3_st_controls,
 +
ARRAY_SIZE(omap_mcbsp3_st_controls));
 +default:
 +break;
 +}
 +
 +return -EINVAL;
 +}
 +EXPORT_SYMBOL_GPL(omap_mcbsp_st_add_controls);
 +
  static int __init snd_omap_mcbsp_init(void)
  {
  return snd_soc_register_dais(omap_mcbsp_dai,
 diff --git a/sound/soc/omap/omap-mcbsp.h 
b/sound/soc/omap/omap-mcbsp.h
 index 1968d03..6c363e5 100644
 --- a/sound/soc/omap/omap-mcbsp.h
 +++ b/sound/soc/omap/omap-mcbsp.h
 @@ -57,4 +57,6

RE: [alsa-devel] [PATCH 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone

2010-01-29 Thread ilkka.koskinen


Hi,

From: ext Liam Girdwood [mailto:l...@slimlogic.co.uk] 
Sent: 28 January, 2010 18:22
On Thu, 2010-01-28 at 17:46 +0200, Ilkka Koskinen wrote:
 Add ASoC interface for OMAP McBSP2 and McBSP3 sidetones.
 
 Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
 ---
  sound/soc/omap/omap-mcbsp.c |  187 
+++
  sound/soc/omap/omap-mcbsp.h |2 +
  2 files changed, 189 insertions(+), 0 deletions(-)
 
 diff --git a/sound/soc/omap/omap-mcbsp.c 
b/sound/soc/omap/omap-mcbsp.c
 index 6bbbd2a..295620b 100644
 --- a/sound/soc/omap/omap-mcbsp.c
 +++ b/sound/soc/omap/omap-mcbsp.c
 @@ -39,6 +39,14 @@

snip

 +/* McBSP Sidetone Switch */
 +static const char *omap_mcbsp_st_status[] = {
 +off,
 +on,
 +};
 +

Should this not be a switch (like a mute switch) rather than an enum
kcontrol ?

Makes sense. I'll change it.

 +static const struct soc_enum omap_mcbsp_st_status_enum[] = {
 +SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(omap_mcbsp_st_status),
 +omap_mcbsp_st_status),
 +};
 +
 +static const struct snd_kcontrol_new omap_mcbsp2_st_controls[] = {
 +SOC_ENUM_EXT(McBSP2 Sidetone Switch, 
omap_mcbsp_st_status_enum[0],
 +omap_mcbsp2_st_get_mode, 
omap_mcbsp2_st_set_mode),
 +OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP2 Sidetone Channel 
0 Volume,
 +  -32768, 32767,
 +  omap_mcbsp2_get_st_ch0_volume,
 +  omap_mcbsp2_set_st_ch0_volume),
 +OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP2 Sidetone Channel 
1 Volume,
 +  -32768, 32767,
 +  omap_mcbsp2_get_st_ch1_volume,
 +  omap_mcbsp2_set_st_ch1_volume),
 +};
 +
 +static const struct snd_kcontrol_new omap_mcbsp3_st_controls[] = {
 +SOC_ENUM_EXT(McBSP3 Sidetone Switch, 
omap_mcbsp_st_status_enum[0],
 +omap_mcbsp3_st_get_mode, 
omap_mcbsp3_st_set_mode),
 +OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP3 Sidetone Channel 
0 Volume,
 +  -32768, 32767,
 +  omap_mcbsp3_get_st_ch0_volume,
 +  omap_mcbsp3_set_st_ch0_volume),
 +OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP3 Sidetone Channel 
1 Volume,
 +  -32768, 32767,
 +  omap_mcbsp3_get_st_ch1_volume,
 +  omap_mcbsp3_set_st_ch1_volume),
 +};
 +
 +int omap_mcbsp_st_add_controls(struct snd_soc_codec *codec, 
int mcbsp_id)
 +{
 +if (!cpu_is_omap34xx())
 +return -ENODEV;
 +
 +switch (mcbsp_id) {
 +case 2: /* McBSP 2 */
 +return snd_soc_add_controls(codec, 
omap_mcbsp2_st_controls,
 +
ARRAY_SIZE(omap_mcbsp2_st_controls));
 +case 3: /* McBSP 3 */
 +return snd_soc_add_controls(codec, 
omap_mcbsp3_st_controls,
 +
ARRAY_SIZE(omap_mcbsp3_st_controls));
 +default:
 +break;
 +}
 +
 +return -1;

-EINVAL;

Oops, thanks.

Cheers, Ilkka

 +}
 +EXPORT_SYMBOL_GPL(omap_mcbsp_st_add_controls);
 +
  static int __init snd_omap_mcbsp_init(void)
  {
  return snd_soc_register_dais(omap_mcbsp_dai,
 diff --git a/sound/soc/omap/omap-mcbsp.h 
b/sound/soc/omap/omap-mcbsp.h
 index 647d2f9..7537435 100644
 --- a/sound/soc/omap/omap-mcbsp.h
 +++ b/sound/soc/omap/omap-mcbsp.h
 @@ -57,4 +57,6 @@ enum omap_mcbsp_div {
  
  extern struct snd_soc_dai omap_mcbsp_dai[NUM_LINKS];
  
 +int omap_mcbsp_st_add_controls(struct snd_soc_codec *codec, 
int mcbsp_id);
 +
  #endif


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/2] twl4030: Do not dereference null pointer in error path

2009-10-20 Thread ilkka.koskinen

 
Hi Samuel,

From: ext Samuel Ortiz [mailto:sa...@linux.intel.com] 
Sent: 19 October, 2009 18:53
On Fri, Oct 16, 2009 at 04:21:41PM +0200, 
ilkka.koski...@nokia.com wrote:
 
 Hi Samuel,
 
 What is the status of this patch and the other one:
 [PATCH 2/2] twl4030: Enable low-power mode to 32KHz oscillator
I'm sorry but it seems I havent received those 2 patches. 
Could you please
re-send them ?

Sorry, my mistake. I already forgot that the patches never
reached you. I'll resend them right away.

Cheers, Ilkka

 -Original Message-
 From: Koskinen Ilkka (Nokia-D/Tampere) 
 Sent: 30 September, 2009 18:12
 To: linux-ker...@vger.kernel.org; sa...@linux.intel.com
 Cc: linux-omap@vger.kernel.org; Koskinen Ilkka (Nokia-D/Tampere)
 Subject: [PATCH 1/2] twl4030: Do not dereference null pointer 
 in error path
 
 Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
 ---
  drivers/mfd/twl4030-core.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
 index e424cf6..8cf0a02 100644
 --- a/drivers/mfd/twl4030-core.c
 +++ b/drivers/mfd/twl4030-core.c
 @@ -792,7 +792,7 @@ twl4030_probe(struct i2c_client *client, 
 const struct i2c_device_id *id)
 twl-client = i2c_new_dummy(client-adapter,
 twl-address);
 if (!twl-client) {
 -   dev_err(twl-client-dev,
 +   dev_err(client-dev,
 can't attach client %d\n, i);
 status = -ENOMEM;
 goto fail;
 -- 
 1.6.0.4
 
 

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/2] twl4030: Do not dereference null pointer in error path

2009-10-16 Thread ilkka.koskinen


Hi Samuel,

What is the status of this patch and the other one:
[PATCH 2/2] twl4030: Enable low-power mode to 32KHz oscillator

Cheers, Ilkka

-Original Message-
From: Koskinen Ilkka (Nokia-D/Tampere) 
Sent: 30 September, 2009 18:12
To: linux-ker...@vger.kernel.org; sa...@linux.intel.com
Cc: linux-omap@vger.kernel.org; Koskinen Ilkka (Nokia-D/Tampere)
Subject: [PATCH 1/2] twl4030: Do not dereference null pointer 
in error path

Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
---
 drivers/mfd/twl4030-core.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index e424cf6..8cf0a02 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -792,7 +792,7 @@ twl4030_probe(struct i2c_client *client, 
const struct i2c_device_id *id)
   twl-client = i2c_new_dummy(client-adapter,
   twl-address);
   if (!twl-client) {
-  dev_err(twl-client-dev,
+  dev_err(client-dev,
   can't attach client %d\n, i);
   status = -ENOMEM;
   goto fail;
-- 
1.6.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] twl4030: Initial support for twl5031

2009-10-14 Thread ilkka.koskinen

 
Hi,

From: ext G, Manjunath Kondaiah [mailto:manj...@ti.com] 
Sent: 14 October, 2009 13:51
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ilkka Koskinen
 Sent: Thursday, September 24, 2009 9:24 PM
 To: linux-ker...@vger.kernel.org; sa...@linux.intel.com
 Cc: linux-omap@vger.kernel.org; felipe.ba...@nokia.com; 
 dbrown...@users.sourceforge.net; ilkka.koski...@nokia.com
 Subject: [PATCH] twl4030: Initial support for twl5031
 
 TWL5031 introduces two new interrupts in PIH. Moreover, BCI
 has changed remarkably and, thus, it's disabled when TWL5031
 is in use.
 
 Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
 ---
  drivers/mfd/twl4030-core.c  |   15 +-
  drivers/mfd/twl4030-irq.c   |  126 
 --
  include/linux/i2c/twl4030.h |   47 ++--
  3 files changed, 175 insertions(+), 13 deletions(-)
 
 diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
 index cd1008c..952bea5 100644
 --- a/drivers/mfd/twl4030-core.c
 +++ b/drivers/mfd/twl4030-core.c
 @@ -134,6 +134,9 @@
  #define TWL4030_BASEADD_PWMB0x00F1
  #define TWL4030_BASEADD_KEYPAD  0x00D2
  
 +#define TWL5031_BASEADD_ACCESSORY   0x0074 /* Replaces Main 
 Charge */
 +#define TWL5031_BASEADD_INTERRUPTS  0x00B9 /* Different to 
 TWL4030's one */
 +
  /* subchip/slave 3 - POWER ID */
  #define TWL4030_BASEADD_BACKUP  0x0014
  #define TWL4030_BASEADD_INT 0x002E
 @@ -164,6 +167,7 @@
  /* chip-specific feature flags, for i2c_device_id.driver_data */
  #define TWL4030_VAUX2   BIT(0)  /* pre-5030 
 voltage ranges */
  #define TPS_SUBSET  BIT(1)  /* tps659[23]0 have 
 fewer LDOs */
 +#define TWL5031 BIT(2)  /* twl5031 has 
 different registers */
  
  
 /*
 --*/
  
 @@ -216,6 +220,8 @@ static struct twl4030mapping 
 twl4030_map[TWL4030_MODULE_LAST + 1] = {
  { 2, TWL4030_BASEADD_PWM1 },
  { 2, TWL4030_BASEADD_PWMA },
  { 2, TWL4030_BASEADD_PWMB },
 +{ 2, TWL5031_BASEADD_ACCESSORY },
 +{ 2, TWL5031_BASEADD_INTERRUPTS },
  
  { 3, TWL4030_BASEADD_BACKUP },
  { 3, TWL4030_BASEADD_INT },
 @@ -464,7 +470,8 @@ add_children(struct twl4030_platform_data 
 *pdata, unsigned long features)
  struct device   *child;
  struct device   *usb_transceiver = NULL;
  
 -if (twl_has_bci()  pdata-bci  !(features  TPS_SUBSET)) {
 +if (twl_has_bci()  pdata-bci 
 +!((features  TPS_SUBSET) || (features  TWL5031))) {
  child = add_child(3, twl4030_bci,
  pdata-bci, sizeof(*pdata-bci),
  false,
 @@ -707,6 +714,7 @@ static void clocks_init(struct device *dev)
  
  int twl_init_irq(int irq_num, unsigned irq_base, unsigned irq_end);
  int twl_exit_irq(void);
 +int twl_init_chip_irq(const char *chip);
  
  static int twl4030_remove(struct i2c_client *client)
  {
 @@ -780,6 +788,10 @@ twl4030_probe(struct i2c_client *client, 
 const struct i2c_device_id *id)
  if (client-irq
   pdata-irq_base
   pdata-irq_end  pdata-irq_base) {
 +status = twl_init_chip_irq(id-name);
 +if (status  0)
 +goto fail;

No need to check since status is always zero.

Right, I'll remove the check.

 +
  status = twl_init_irq(client-irq, 
 pdata-irq_base, pdata-irq_end);
  if (status  0)
  goto fail;
 @@ -795,6 +807,7 @@ fail:
  static const struct i2c_device_id twl4030_ids[] = {
  { twl4030, TWL4030_VAUX2 },   /* Triton 2 */
  { twl5030, 0 },   /* T2 updated */
 +{ twl5031, TWL5031 }, /* TWL5030 updated */
  { tps65950, 0 },  /* catalog version of twl5030 */
  { tps65930, TPS_SUBSET }, /* fewer LDOs and DACs; 
 no charger */
  { tps65920, TPS_SUBSET }, /* fewer LDOs; no codec 
 or charger */
 diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
 index aca2670..d781788 100644
 --- a/drivers/mfd/twl4030-irq.c
 +++ b/drivers/mfd/twl4030-irq.c
 @@ -61,6 +61,7 @@
  
  /* Linux could (eventually) use either IRQ line */
  static int irq_line;
 +static int chip_is_twl5031;
  
  struct sih {
  charname[8];
 @@ -82,6 +83,9 @@ struct sih {
  /* + 2 bytes padding */
  };
  
 +static const struct sih *sih_modules;
 +static int nr_sih_modules;
 +
  #define SIH_INITIALIZER(modname, nbits) \
  .module = TWL4030_MODULE_ ## modname, \
  .control_offset = TWL4030_ ## modname ## _SIH_CTRL, \
 @@ -107,7 +111,7 @@ struct sih {
  /* Order in this table matches order in PIH_ISR.  That is,
   * BIT(n) in PIH_ISR is sih_modules[n].
   */
 -static const struct sih sih_modules[6] = {
 +static const struct sih sih_modules_twl4030[6] = {
  [0] = {
  .name   = gpio,

RE: [PATCH] rtc-twl: Switch to using threaded irq

RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone

RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone

RE: [PATCHv2 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone

RE: [alsa-devel] [PATCH 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone

RE: [PATCH 1/2] twl4030: Do not dereference null pointer in error path

RE: [PATCH 1/2] twl4030: Do not dereference null pointer in error path

RE: [PATCH] twl4030: Initial support for twl5031

8 matches

Site Navigation

Mail list logo

Footer information