Required platform information is not handed to max8997-irq.c properly.
This patch enables to hand over such information to max8997-irq.c so
that max8997-irq functions properly.
Signed-off-by: MyungJoo Ham <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
---
drivers/mfd/max8997.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/max8997.c b/drivers/mfd/max8997.c
index 5d1fca0..f83103b 100644
--- a/drivers/mfd/max8997.c
+++ b/drivers/mfd/max8997.c
@@ -135,10 +135,13 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
max8997->dev = &i2c->dev;
max8997->i2c = i2c;
max8997->type = id->driver_data;
+ max8997->irq = i2c->irq;
if (!pdata)
goto err;
+ max8997->irq_base = pdata->irq_base;
+ max8997->ono = pdata->ono;
max8997->wakeup = pdata->wakeup;
mutex_init(&max8997->iolock);
@@ -152,6 +155,8 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
pm_runtime_set_active(max8997->dev);
+ max8997_irq_init(max8997);
+
mfd_add_devices(max8997->dev, -1, max8997_devs,
ARRAY_SIZE(max8997_devs),
NULL, 0);
--
1.7.4.1
- Support wake-up from suspend-to-ram.
- Handle pending interrupt after a resume.
Signed-off-by: MyungJoo Ham <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
---
drivers/mfd/max8997.c | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/max8997.c b/drivers/mfd/max8997.c
index f83103b..4ae42c6 100644
--- a/drivers/mfd/max8997.c
+++ b/drivers/mfd/max8997.c
@@ -23,6 +23,7 @@
#include <linux/slab.h>
#include <linux/i2c.h>
+#include <linux/interrupt.h>
#include <linux/pm_runtime.h>
#include <linux/mutex.h>
#include <linux/mfd/core.h>
@@ -398,7 +399,29 @@ static int max8997_restore(struct device *dev)
return 0;
}
+static int max8997_suspend(struct device *dev)
+{
+ struct i2c_client *i2c = container_of(dev, struct i2c_client, dev);
+ struct max8997_dev *max8997 = i2c_get_clientdata(i2c);
+
+ if (max8997->wakeup && max8997->irq)
+ irq_set_irq_wake(max8997->irq, 1);
+ return 0;
+}
+
+static int max8997_resume(struct device *dev)
+{
+ struct i2c_client *i2c = container_of(dev, struct i2c_client, dev);
+ struct max8997_dev *max8997 = i2c_get_clientdata(i2c);
+
+ if (max8997->wakeup && max8997->irq)
+ irq_set_irq_wake(max8997->irq, 0);
+ return max8997_irq_resume(max8997);
+}
+
const struct dev_pm_ops max8997_pm = {
+ .suspend = max8997_suspend,
+ .resume = max8997_resume,
.freeze = max8997_freeze,
.restore = max8997_restore,
};
--
1.7.4.1
IRQ definitions are needed to be accessed by board support package codes
as well. Because they are not only used by MAX8997 MFD device drivers,
this patch pulls such definitions out of private header, which is meant
for MAX8997 MFD device drivers.
Signed-off-by: MyungJoo Ham <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
---
include/linux/mfd/max8997-private.h | 46 -----------------------------------
include/linux/mfd/max8997.h | 46 +++++++++++++++++++++++++++++++++++
2 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/include/linux/mfd/max8997-private.h b/include/linux/mfd/max8997-private.h
index 5ff2400..4e50a62 100644
--- a/include/linux/mfd/max8997-private.h
+++ b/include/linux/mfd/max8997-private.h
@@ -265,52 +265,6 @@ enum max8997_irq_source {
MAX8997_IRQ_GROUP_NR,
};
-enum max8997_irq {
- MAX8997_PMICIRQ_PWRONR,
- MAX8997_PMICIRQ_PWRONF,
- MAX8997_PMICIRQ_PWRON1SEC,
- MAX8997_PMICIRQ_JIGONR,
- MAX8997_PMICIRQ_JIGONF,
- MAX8997_PMICIRQ_LOWBAT2,
- MAX8997_PMICIRQ_LOWBAT1,
-
- MAX8997_PMICIRQ_JIGR,
- MAX8997_PMICIRQ_JIGF,
- MAX8997_PMICIRQ_MR,
- MAX8997_PMICIRQ_DVS1OK,
- MAX8997_PMICIRQ_DVS2OK,
- MAX8997_PMICIRQ_DVS3OK,
- MAX8997_PMICIRQ_DVS4OK,
-
- MAX8997_PMICIRQ_CHGINS,
- MAX8997_PMICIRQ_CHGRM,
- MAX8997_PMICIRQ_DCINOVP,
- MAX8997_PMICIRQ_TOPOFFR,
- MAX8997_PMICIRQ_CHGRSTF,
- MAX8997_PMICIRQ_MBCHGTMEXPD,
-
- MAX8997_PMICIRQ_RTC60S,
- MAX8997_PMICIRQ_RTCA1,
- MAX8997_PMICIRQ_RTCA2,
- MAX8997_PMICIRQ_SMPL_INT,
- MAX8997_PMICIRQ_RTC1S,
- MAX8997_PMICIRQ_WTSR,
-
- MAX8997_MUICIRQ_ADCError,
- MAX8997_MUICIRQ_ADCLow,
- MAX8997_MUICIRQ_ADC,
-
- MAX8997_MUICIRQ_VBVolt,
- MAX8997_MUICIRQ_DBChg,
- MAX8997_MUICIRQ_DCDTmr,
- MAX8997_MUICIRQ_ChgDetRun,
- MAX8997_MUICIRQ_ChgTyp,
-
- MAX8997_MUICIRQ_OVP,
-
- MAX8997_IRQ_NR,
-};
-
#define MAX8997_NUM_GPIO 12
struct max8997_dev {
struct device *dev;
diff --git a/include/linux/mfd/max8997.h b/include/linux/mfd/max8997.h
index 0bbd13d..90e7731 100644
--- a/include/linux/mfd/max8997.h
+++ b/include/linux/mfd/max8997.h
@@ -119,4 +119,50 @@ struct max8997_platform_data {
/* Flash: Not implemented */
};
+enum max8997_irq {
+ MAX8997_PMICIRQ_PWRONR,
+ MAX8997_PMICIRQ_PWRONF,
+ MAX8997_PMICIRQ_PWRON1SEC,
+ MAX8997_PMICIRQ_JIGONR,
+ MAX8997_PMICIRQ_JIGONF,
+ MAX8997_PMICIRQ_LOWBAT2,
+ MAX8997_PMICIRQ_LOWBAT1,
+
+ MAX8997_PMICIRQ_JIGR,
+ MAX8997_PMICIRQ_JIGF,
+ MAX8997_PMICIRQ_MR,
+ MAX8997_PMICIRQ_DVS1OK,
+ MAX8997_PMICIRQ_DVS2OK,
+ MAX8997_PMICIRQ_DVS3OK,
+ MAX8997_PMICIRQ_DVS4OK,
+
+ MAX8997_PMICIRQ_CHGINS,
+ MAX8997_PMICIRQ_CHGRM,
+ MAX8997_PMICIRQ_DCINOVP,
+ MAX8997_PMICIRQ_TOPOFFR,
+ MAX8997_PMICIRQ_CHGRSTF,
+ MAX8997_PMICIRQ_MBCHGTMEXPD,
+
+ MAX8997_PMICIRQ_RTC60S,
+ MAX8997_PMICIRQ_RTCA1,
+ MAX8997_PMICIRQ_RTCA2,
+ MAX8997_PMICIRQ_SMPL_INT,
+ MAX8997_PMICIRQ_RTC1S,
+ MAX8997_PMICIRQ_WTSR,
+
+ MAX8997_MUICIRQ_ADCError,
+ MAX8997_MUICIRQ_ADCLow,
+ MAX8997_MUICIRQ_ADC,
+
+ MAX8997_MUICIRQ_VBVolt,
+ MAX8997_MUICIRQ_DBChg,
+ MAX8997_MUICIRQ_DCDTmr,
+ MAX8997_MUICIRQ_ChgDetRun,
+ MAX8997_MUICIRQ_ChgTyp,
+
+ MAX8997_MUICIRQ_OVP,
+
+ MAX8997_IRQ_NR,
+};
+
#endif /* __LINUX_MFD_MAX8998_H */
--
1.7.4.1
On Thu, Jun 30, 2011 at 10:31:47AM +0900, MyungJoo Ham wrote:
> IRQ definitions are needed to be accessed by board support package codes
> as well. Because they are not only used by MAX8997 MFD device drivers,
> this patch pulls such definitions out of private header, which is meant
> for MAX8997 MFD device drivers.
Why is this needed?
On Thu, Jun 30, 2011 at 2:28 PM, Mark Brown
<[email protected]> wrote:
> On Thu, Jun 30, 2011 at 10:31:47AM +0900, MyungJoo Ham wrote:
>> IRQ definitions are needed to be accessed by board support package codes
>> as well. Because they are not only used by MAX8997 MFD device drivers,
>> this patch pulls such definitions out of private header, which is meant
>> for MAX8997 MFD device drivers.
>
> Why is this needed?
>
In order to request MAX8997's IRQs, these IRQ enums are required by
board files (such as /arch/arm/mach-exynos4/mach-*.c). So, these IRQ
enums are no more "private" to max8997 device drivers. Without this
patch, board files need to include max8997-private.h.
It works properly with or without the patch. The patch is only for
some aesthetics reasons.
However, this max8997-private.h was meant to be included by device
drivers of MAX8997-MFD (such as MAX8997-PMIC, MAX8997-RTC,
MAX8997-IRQ, ...); thus, including that private header at board files
(or any other non-max8997 device drivers) didn't look "proper". If
these "private" MFD headers are to be included by non "subdevices" of
the same MFD, it is meaningless to seperate into two headers
(max8997.h and max8997-private.h) and we'd better merge public and
private headers of MFDs.
Cheers!
- MyungJoo
--
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
On Thu, Jun 30, 2011 at 02:56:27PM +0900, MyungJoo Ham wrote:
> In order to request MAX8997's IRQs, these IRQ enums are required by
> board files (such as /arch/arm/mach-exynos4/mach-*.c). So, these IRQ
> enums are no more "private" to max8997 device drivers. Without this
> patch, board files need to include max8997-private.h.
Why does the board file need to request these IRQs?
On Thu, Jun 30, 2011 at 2:57 PM, Mark Brown
<[email protected]> wrote:
> On Thu, Jun 30, 2011 at 02:56:27PM +0900, MyungJoo Ham wrote:
>
>> In order to request MAX8997's IRQs, these IRQ enums are required by
>> board files (such as /arch/arm/mach-exynos4/mach-*.c). So, these IRQ
>> enums are no more "private" to max8997 device drivers. Without this
>> patch, board files need to include max8997-private.h.
>
> Why does the board file need to request these IRQs?
>
It specifies which interrupts of MAX8997 are used.
In our code:
http://git.infradead.org/users/kmpark/linux-2.6-samsung/blob/eba500212699c0ad8d6bde0dc01c3ec7101f8154:/arch/arm/mach-exynos4/setup-charger.c
around line 85, it specifies which interrupt is going to be a
wakeup-source ("true"), how the power-managing S/W should interpret
them.
The interrupts not listed in the array are not used as a wakeup-source.
--
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
On Thu, Jun 30, 2011 at 05:00:13PM +0900, MyungJoo Ham wrote:
> In our code:
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/blob/eba500212699c0ad8d6bde0dc01c3ec7101f8154:/arch/arm/mach-exynos4/setup-charger.c
> around line 85, it specifies which interrupt is going to be a
> wakeup-source ("true"), how the power-managing S/W should interpret
> them.
This looks like charger specific configuration which should be done by
the charger driver rather than by directly working with the IRQs?
On Fri, Jul 1, 2011 at 12:56 AM, Mark Brown
<[email protected]> wrote:
> On Thu, Jun 30, 2011 at 05:00:13PM +0900, MyungJoo Ham wrote:
>
>> In our code:
>> http://git.infradead.org/users/kmpark/linux-2.6-samsung/blob/eba500212699c0ad8d6bde0dc01c3ec7101f8154:/arch/arm/mach-exynos4/setup-charger.c
>> around line 85, it specifies which interrupt is going to be a
>> wakeup-source ("true"), how the power-managing S/W should interpret
>> them.
>
> This looks like charger specific configuration which should be done by
> the charger driver rather than by directly working with the IRQs?
>
Well, the issue is that the charger driver just does not know what to
do with its own interrupts.
For example, each board has different regulator setting for DCIN
depending on the specification of the board (some uses 450mA
constantly, some uses 450mA and 700mA depending on the connection
information, which is not known to charger driver, some uses 900mA
unconditionally, and so on).
Sometimes setting the attributes of a charger at its own interrupts
depends on the status of another charger; when we have USB charger,
wireless charger, and solar panels, which may be enabled independently
and have their own device drivers.
Scenarios that we are going to support include limiting the aggregated
charging flow, stopping every charger for an error detected at a
single charger (only for really critical ones that imply that the
battery itself has a major issue) as usually only one of the chargers
has sophiscated sensors and controls, and disabling a charger when
others are active (e.g., when CC charging is finished and CV charging
is going on with little current).
In that charger specific configuration and its driver, we are trying
to aggregate multiple chargers (although we specified only two
independent chargers, not three, in that example).
Thanks,
- MyungJoo
--
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858