[PATCH 1/4] mfd: support 88pm80x in 80x driver
88PM800 and 88PM805 are two discrete chips used for power management. Hardware designer can use them together or only one of them according to requirement. 88pm80x_i2c.c provides common i2c driver handling for both 800 and 805, such as i2c_driver init, regmap init, read/write api etc. 88pm800_core.c handles specifically for 800, such as chip init, irq init/handle, mfd device register, including rtc, onkey, regulator( to be add later) etc. besides that, 800 has three i2c device, one regular i2c client, two other i2c dummy for gpadc and power purpose. 88pm805_core.c handles specifically for 805, such as chip init, irq init/handle, mfd device register, including codec, headset/mic detect etc. the i2c operation of both 800 and 805 are via regmap, and 88pm80x-i2c exported a group of r/w bulk r/w and bits set API for facility. Signed-off-by: Qiao Zhou --- drivers/mfd/88pm800-core.c | 593 +++ drivers/mfd/88pm805-core.c | 299 ++ drivers/mfd/88pm80x-i2c.c | 116 + drivers/mfd/Kconfig | 24 ++ drivers/mfd/Makefile|3 + include/linux/mfd/88pm80x.h | 376 +++ 6 files changed, 1411 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/88pm800-core.c create mode 100644 drivers/mfd/88pm805-core.c create mode 100644 drivers/mfd/88pm80x-i2c.c create mode 100644 include/linux/mfd/88pm80x.h diff --git a/drivers/mfd/88pm800-core.c b/drivers/mfd/88pm800-core.c new file mode 100644 index 000..fe479cc --- /dev/null +++ b/drivers/mfd/88pm800-core.c @@ -0,0 +1,593 @@ +/* + * Base driver for Marvell 88PM800 + * + * Copyright (C) 2012 Marvell International Ltd. + * Haojian Zhuang + * Joseph(Yossi) Hanin + * Qiao Zhou + * + * This file is subject to the terms and conditions of the GNU General + * Public License. See the file "COPYING" in the main directory of this + * archive for more details. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include +#include + +#define PM800_CHIP_ID (0x00) + +/* Interrupt Registers */ +#define PM800_INT_STATUS1 (0x05) +#define PM800_ONKEY_INT_STS1 (1 << 0) +#define PM800_EXTON_INT_STS1 (1 << 1) +#define PM800_CHG_INT_STS1 (1 << 2) +#define PM800_BAT_INT_STS1 (1 << 3) +#define PM800_RTC_INT_STS1 (1 << 4) +#define PM800_CLASSD_OC_INT_STS1 (1 << 5) + +#define PM800_INT_STATUS2 (0x06) +#define PM800_VBAT_INT_STS2(1 << 0) +#define PM800_VSYS_INT_STS2(1 << 1) +#define PM800_VCHG_INT_STS2(1 << 2) +#define PM800_TINT_INT_STS2(1 << 3) +#define PM800_GPADC0_INT_STS2 (1 << 4) +#define PM800_TBAT_INT_STS2(1 << 5) +#define PM800_GPADC2_INT_STS2 (1 << 6) +#define PM800_GPADC3_INT_STS2 (1 << 7) + +#define PM800_INT_STATUS3 (0x07) + +#define PM800_INT_STATUS4 (0x08) +#define PM800_GPIO0_INT_STS4 (1 << 0) +#define PM800_GPIO1_INT_STS4 (1 << 1) +#define PM800_GPIO2_INT_STS4 (1 << 2) +#define PM800_GPIO3_INT_STS4 (1 << 3) +#define PM800_GPIO4_INT_STS4 (1 << 4) + +#define PM800_INT_ENA_1(0x09) +#define PM800_ONKEY_INT_ENA1 (1 << 0) +#define PM800_EXTON_INT_ENA1 (1 << 1) +#define PM800_CHG_INT_ENA1 (1 << 2) +#define PM800_BAT_INT_ENA1 (1 << 3) +#define PM800_RTC_INT_ENA1 (1 << 4) +#define PM800_CLASSD_OC_INT_ENA1 (1 << 5) + +#define PM800_INT_ENA_2(0x0A) +#define PM800_VBAT_INT_ENA2(1 << 0) +#define PM800_VSYS_INT_ENA2(1 << 1) +#define PM800_VCHG_INT_ENA2(1 << 2) +#define PM800_TINT_INT_ENA2(1 << 3) + +#define PM800_INT_ENA_3(0x0B) +#define PM800_GPADC0_INT_ENA3 (1 << 0) +#define PM800_GPADC1_INT_ENA3 (1 << 1) +#define PM800_GPADC2_INT_ENA3 (1 << 2) +#define PM800_GPADC3_INT_ENA3 (1 << 3) +#define PM800_GPADC4_INT_ENA3 (1 << 4) + +#define PM800_INT_ENA_4(0x0C) +#define PM800_GPIO0_INT_ENA4 (1 << 0) +#define PM800_GPIO1_INT_ENA4 (1 << 1) +#define PM800_GPIO2_INT_ENA4 (1 << 2) +#define PM800_GPIO3_INT_ENA4 (1 << 3) +#define PM800_GPIO4_INT_ENA4 (1 << 4) + +/* number of INT_ENA & INT_STATUS regs */ +#define PM800_INT_REG_NUM (4) + +/* Int
[PATCH 3/4] rtc: add rtc support to 88PM80X PMIC
add rtc driver for MARVELL 88PM80X PMIC and enable rtc function.
Signed-off-by: Qiao Zhou
---
drivers/rtc/Kconfig | 10 ++
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-88pm80x.c | 371 +
3 files changed, 382 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-88pm80x.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 08cbdb9..f049c02 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -135,6 +135,16 @@ config RTC_DRV_88PM860X
This driver can also be built as a module. If so, the module
will be called rtc-88pm860x.
+config RTC_DRV_88PM80X
+ tristate "Marvell 88PM80x"
+ depends on RTC_CLASS && I2C && MFD_88PM800
+ help
+ If you say yes here you get support for RTC function in Marvell
+ 88PM80x chips.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-88pm80x.
+
config RTC_DRV_DS1307
tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 2973921..0d5b2b6 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -16,6 +16,7 @@ rtc-core-$(CONFIG_RTC_INTF_SYSFS) += rtc-sysfs.o
# Keep the list ordered.
obj-$(CONFIG_RTC_DRV_88PM860X) += rtc-88pm860x.o
+obj-$(CONFIG_RTC_DRV_88PM80X) += rtc-88pm80x.o
obj-$(CONFIG_RTC_DRV_AB3100) += rtc-ab3100.o
obj-$(CONFIG_RTC_DRV_AB8500) += rtc-ab8500.o
obj-$(CONFIG_RTC_DRV_AT32AP700X)+= rtc-at32ap700x.o
diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
new file mode 100644
index 000..a2f956d
--- /dev/null
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -0,0 +1,371 @@
+/*
+ * Real Time Clock driver for Marvell 88PM80x PMIC
+ *
+ * Copyright (c) 2012 Marvell International Ltd.
+ * Wenzeng Chen
+ * Qiao Zhou
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PM800_RTC_COUNTER1 (0xD1)
+#define PM800_RTC_COUNTER2 (0xD2)
+#define PM800_RTC_COUNTER3 (0xD3)
+#define PM800_RTC_COUNTER4 (0xD4)
+#define PM800_RTC_EXPIRE1_1(0xD5)
+#define PM800_RTC_EXPIRE1_2(0xD6)
+#define PM800_RTC_EXPIRE1_3(0xD7)
+#define PM800_RTC_EXPIRE1_4(0xD8)
+#define PM800_RTC_TRIM1(0xD9)
+#define PM800_RTC_TRIM2(0xDA)
+#define PM800_RTC_TRIM3(0xDB)
+#define PM800_RTC_TRIM4(0xDC)
+#define PM800_RTC_EXPIRE2_1(0xDD)
+#define PM800_RTC_EXPIRE2_2(0xDE)
+#define PM800_RTC_EXPIRE2_3(0xDF)
+#define PM800_RTC_EXPIRE2_4(0xE0)
+
+#define PM800_POWER_DOWN_LOG1 (0xE5)
+#define PM800_POWER_DOWN_LOG2 (0xE6)
+
+struct pm80x_rtc_info {
+ struct pm80x_chip *chip;
+ struct regmap *map;
+ struct rtc_device *rtc_dev;
+ struct device *dev;
+ struct delayed_work calib_work;
+
+ int irq;
+ int vrtc;
+};
+
+static irqreturn_t rtc_update_handler(int irq, void *data)
+{
+ struct pm80x_rtc_info *info = (struct pm80x_rtc_info *)data;
+ int mask;
+
+ mask = PM800_ALARM | PM800_ALARM_WAKEUP;
+ regmap_update_bits(info->map, PM800_RTC_CONTROL, mask | PM800_ALARM1_EN,
+ mask);
+ rtc_update_irq(info->rtc_dev, 1, RTC_AF);
+ return IRQ_HANDLED;
+}
+
+static int pm80x_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
+{
+ struct pm80x_rtc_info *info = dev_get_drvdata(dev);
+
+ if (enabled)
+ regmap_update_bits(info->map, PM800_RTC_CONTROL,
+ PM800_ALARM1_EN, PM800_ALARM1_EN);
+ else
+ regmap_update_bits(info->map, PM800_RTC_CONTROL,
+ PM800_ALARM1_EN, 0);
+ return 0;
+}
+
+/*
+ * Calculate the next alarm time given the requested alarm time mask
+ * and the current time.
+ */
+static void rtc_next_alarm_time(struct rtc_time *next, struct rtc_time *now,
+ struct rtc_time *alrm)
+{
+ unsigned long next_time;
+ unsigned long now_time;
+
+ next->tm_year = now->tm_year;
+ next->tm_mon = now->tm_mon;
+ next->tm_mday = now->tm
[PATCH 4/4] input: add onkey support to 88PM80X PMIC
add onkey support to MARVELL 88PM80X PMIC.
Signed-off-by: Qiao Zhou
---
drivers/input/misc/88pm80x_onkey.c | 176
drivers/input/misc/Kconfig | 10 ++
drivers/input/misc/Makefile|1 +
3 files changed, 187 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/88pm80x_onkey.c
diff --git a/drivers/input/misc/88pm80x_onkey.c
b/drivers/input/misc/88pm80x_onkey.c
new file mode 100644
index 000..807587f
--- /dev/null
+++ b/drivers/input/misc/88pm80x_onkey.c
@@ -0,0 +1,176 @@
+/*
+ * 88pm80x_onkey.c - Marvell 88PM80x ONKEY driver
+ *
+ * Copyright (C) 2012 Marvell International Ltd.
+ * Haojian Zhuang
+ * Qiao Zhou
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PM800_LONG_ONKEY_EN(1 << 0)
+#define PM800_LONG_KEY_DELAY (8) /* 1 .. 16 seconds */
+#define PM800_LONKEY_PRESS_TIME((PM800_LONG_KEY_DELAY-1) << 4)
+#define PM800_LONKEY_PRESS_TIME_MASK (0xF0)
+#define PM800_SW_PDOWN (1 << 5)
+
+struct pm80x_onkey_info {
+ struct input_dev *idev;
+ struct pm80x_chip *pm80x;
+ struct regmap *map;
+ int irq;
+};
+
+/* 88PM80x gives us an interrupt when ONKEY is held */
+static irqreturn_t pm80x_onkey_handler(int irq, void *data)
+{
+ struct pm80x_onkey_info *info = data;
+ int ret = 0;
+
+ regmap_read(info->map, PM800_STATUS_1, &ret);
+ ret &= PM800_ONKEY_STS1;
+
+ input_report_key(info->idev, KEY_POWER, ret);
+ input_sync(info->idev);
+
+ return IRQ_HANDLED;
+}
+
+#ifdef CONFIG_PM
+static int pm80x_onkey_suspend(struct device *dev)
+{
+ return pm80x_dev_suspend(dev);
+}
+
+static int pm80x_onkey_resume(struct device *dev)
+{
+ return pm80x_dev_resume(dev);
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(pm80x_onkey_pm_ops, pm80x_onkey_suspend,
+pm80x_onkey_resume);
+
+static int __devinit pm80x_onkey_probe(struct platform_device *pdev)
+{
+
+ void *chip = dev_get_drvdata(pdev->dev.parent);
+ struct pm80x_onkey_info *info;
+ int ret;
+
+ info =
+ devm_kzalloc(&pdev->dev, sizeof(struct pm80x_onkey_info),
+GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ info->pm80x = (struct pm80x_chip *)chip;
+
+ info->irq = platform_get_irq(pdev, 0);
+ if (info->irq < 0) {
+ dev_err(&pdev->dev, "No IRQ resource!\n");
+ return -EINVAL;
+ }
+
+ info->map = info->pm80x->regmap;
+ if (!info->map) {
+ dev_err(&pdev->dev, "no regmap!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ info->idev = input_allocate_device();
+ if (!info->idev) {
+ dev_err(&pdev->dev, "Failed to allocate input dev\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ info->idev->name = "88pm80x_on";
+ info->idev->phys = "88pm80x_on/input0";
+ info->idev->id.bustype = BUS_I2C;
+ info->idev->dev.parent = &pdev->dev;
+ info->idev->evbit[0] = BIT_MASK(EV_KEY);
+ info->idev->keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
+
+ ret = input_register_device(info->idev);
+ if (ret) {
+ dev_err(&pdev->dev, "Can't register input device: %d\n", ret);
+ goto out_reg;
+ }
+
+ ret = pm80x_request_irq(info->pm80x, info->irq, pm80x_onkey_handler,
+ IRQF_ONESHOT, "onkey", info);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to request IRQ: #%d: %d\n",
+ info->irq, ret);
+ goto out_irq;
+ }
+
+ platform_set_drvdata(pdev, info);
+
+ /* Enable long onkey detection */
+ regmap_update_bits(info->map, PM800_RTC_MISC4, PM800_LONG_ONKEY_EN,
+ PM800_LONG_ONKEY_EN);
+ /* Set 8-second interval */
+ regmap_update_bits(info->map, PM800_RTC_MISC3,
+ PM800_LONKEY_PRESS_TIME_MASK,
+ PM800_LONKEY_PRESS_TIME);
+
+ device_init_wakeup(&pdev->dev, 1);
+ return 0;
+
+out_irq:
+ input_unregister_device(info->idev);
+out_reg:
+ input_free_device(info->idev);
+out
[PATCH 2/4] mfd: workaround: add companion chip in 88pm80x
in hw design, 800 is mainly for pmic control, while 805 for audio.
but there are 3 registers which controls class D speaker property,
and they are defined in 800 i2c client domain. so 805 codec driver
needs to use 800 i2c client to access class D speaker reg for
audio path management. so add this workaround for the purpose to
let 805 access 800 i2c in some scenario.
Signed-off-by: Qiao Zhou
---
drivers/mfd/88pm80x-i2c.c | 28
include/linux/mfd/88pm80x.h |1 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/88pm80x-i2c.c b/drivers/mfd/88pm80x-i2c.c
index 90aa18a..77b8655 100644
--- a/drivers/mfd/88pm80x-i2c.c
+++ b/drivers/mfd/88pm80x-i2c.c
@@ -18,6 +18,12 @@
#include
#include
+/*
+ * workaround: some registers needed by pm805 are defined in pm800, so
+ * need to use this global variable to maintain the relation between
+ * pm800 and pm805. would remove it after HW chip fixes the issue.
+ */
+static struct pm80x_chip *g_pm80x_chip;
const struct regmap_config pm80x_regmap_config = {
.reg_bits = 8,
@@ -61,6 +67,19 @@ int __devinit pm80x_init(struct i2c_client *client,
device_init_wakeup(&client->dev, 1);
+ /*
+* workaround: set g_pm80x_chip to the first probed chip. if the
+* second chip is probed, just point to the companion to each
+* other so that pm805 can access those specific register. would
+* remove it after HW chip fixes the issue.
+*/
+ if (!g_pm80x_chip)
+ g_pm80x_chip = chip;
+ else {
+ chip->companion = g_pm80x_chip->client;
+ g_pm80x_chip->companion = chip->client;
+ }
+
return 0;
err_chip_id:
@@ -75,6 +94,15 @@ int __devexit pm80x_deinit(struct i2c_client *client)
{
struct pm80x_chip *chip = i2c_get_clientdata(client);
+ /*
+* workaround: clear the dependency between pm800 and pm805.
+* would remove it after HW chip fixes the issue.
+*/
+ if (g_pm80x_chip->companion)
+ g_pm80x_chip->companion = NULL;
+ else
+ g_pm80x_chip = NULL;
+
regmap_exit(chip->regmap);
devm_kfree(&client->dev, chip);
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 283c903..d8b7dda 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -295,6 +295,7 @@ struct pm80x_chip {
struct pm80x_subchip *subchip;
struct device *dev;
struct i2c_client *client;
+ struct i2c_client *companion;
struct regmap *regmap;
struct regmap_irq_chip *regmap_irq_chip;
struct regmap_irq_chip_data *irq_data;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4 V4] add 88pm80x mfd driver
change log [v4->v3]: 1, provide unified suspend/resume api for all sub-devices, and add protection for 800 & 805 wakeup flag in SMP case. 2, clean register definition in 88pm80x.h, and thanks Arnd's help. 3, some minor changes in mfd Kconfig/Makefile. change log [v3->v2]: 1, dynamically get the irq_base, for both regmap_add_irq_chip and mfd_add_devices. add pm80x_request_irq & pm80x_free_irq for sub-driver facility, and modify related irq thread operation. remove irq_base member from 80x_chip & platform data. 2, split 88pm80x.o into 3 separate modules. 3, remove the 88pm80x r/w API, and directly use open-coded regmap api. 4, minor change: move pm80x_id_table from 80x-i2c.c to 800/805-core.c, exported pm80x_init, pm80x_deinit, and pm80x_bulk_read, add callback in pdata. change log [v2->v1]: 1, split 88pm80x-core.c into 88pm800-core.c and 88pm805.c, per Arnd's suggestion. after the re-arch, 88pm80x-i2c handles the 800 & 805 common parts, while 800-core.c & 805-core.c handle the specific parts in each chip. 2, add details about the workaround adding a i2c companion between 800 & 805, and make a separate patch for it, per Arnd's suggestion. 3, remove callback in pdata. but still keep the pdata currently. 4, only keep necessary register in 88pm80x.h, including registers for regulator/rtc/onkey/power/codec etc, and remove other registers from global visibility. 5, exported r/w API which requires regmap handle. as currently the pm800 chip has 3 i2c device, only passing a pm80x_chip info can't ensure r/w the register in correct i2c device. change log [v1]: 1, pm800 and pm805 are decoupled and probed separately; 2, re-used the most of API for pm800 and pm805 per Arnd's comments; 3, use regmap_irq, instead of previous 88pm80x_irq_data per Mark's comments. use regmap_add_irq_chip, and remove previous 88pm80x irq handling. 4, remove callback function in rtc pdata per Arnd's comments. 5, updated some coding style issue. Qiao Zhou (4): mfd: support 88pm80x in 80x driver mfd: workaround: add companion chip in 88pm80x rtc: add rtc support to 88PM80X PMIC input: add onkey support to 88PM80X PMIC drivers/input/misc/88pm80x_onkey.c | 176 +++ drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile|1 + drivers/mfd/88pm800-core.c | 593 drivers/mfd/88pm805-core.c | 299 ++ drivers/mfd/88pm80x-i2c.c | 144 + drivers/mfd/Kconfig| 24 ++ drivers/mfd/Makefile |3 + drivers/rtc/Kconfig| 10 + drivers/rtc/Makefile |1 + drivers/rtc/rtc-88pm80x.c | 371 ++ include/linux/mfd/88pm80x.h| 377 +++ 12 files changed, 2009 insertions(+), 0 deletions(-) create mode 100644 drivers/input/misc/88pm80x_onkey.c create mode 100644 drivers/mfd/88pm800-core.c create mode 100644 drivers/mfd/88pm805-core.c create mode 100644 drivers/mfd/88pm80x-i2c.c create mode 100644 drivers/rtc/rtc-88pm80x.c create mode 100644 include/linux/mfd/88pm80x.h -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c i.MX: Fix divider table
On Fri, Jul 06, 2012 at 08:52:50AM +0800, Richard Zhao wrote: > On Thu, Jul 05, 2012 at 06:01:53PM +0200, Sascha Hauer wrote: > > On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > > > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > > > Measurements on i.MX1 and i.MX53 have shown that the divider values > > > > in the datasheets are wrong. the values from first, third and fourth > > > > column were all measured to be 8 higher than in the datasheet. It > > > > should be safe to assume that the SoCs between i.MX1 and i.MX53 behave > > > > the same as the i2c unit is unchanged since the i.MX1. > > > We may need to check with IC guys? Or you've done? > > > > I don't have contact to the IC guys. Could you do this? I'd be > > interested in the results. > Sure, but it may be slow, as you know, many people are in summer break. Thanks. It can take longer, the resulting frequencies are all too low, so we are on the safe side. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 V2] MXS: Implement DMA support into mxs-i2c
This patch implements DMA support into mxs-i2c. DMA transfers are now enabled
via DT. The DMA operation is enabled by default.
Signed-off-by: Marek Vasut
Cc: Detlev Zundel
CC: Dong Aisheng
CC: Fabio Estevam
Cc: Linux ARM kernel
Cc: linux-i2c@vger.kernel.org
CC: Sascha Hauer
CC: Shawn Guo
Cc: Stefano Babic
CC: Uwe Kleine-König
Cc: Wolfgang Denk
Cc: Wolfram Sang
---
Documentation/devicetree/bindings/i2c/i2c-mxs.txt |5 +
arch/arm/boot/dts/imx28.dtsi |2 +
drivers/i2c/busses/i2c-mxs.c | 267 +++--
3 files changed, 252 insertions(+), 22 deletions(-)
V2: (even though technically V, ditto here, slaps himself)
Fixed return value from mxs_i2c_dma_setup_xfer(), pointed by Dong.
Fixed coding style nitpicks
Call mxs_i2c_dma_finish() in failpath only if DMA is active
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
index 2ed5332..d337cbc 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
@@ -5,6 +5,10 @@ Required properties:
- reg: Should contain registers location and length
- interrupts: Should contain ERROR and DMA interrupts
- clock-frequency: desired I2C bus clock frequency in Hz.
+- fsl,i2c-dma-channel: APBX DMA channel for the I2C
+
+Optional properties:
+- fsl,use-pio: Use PIO transfers instead of DMA, useful for debug
Examples:
@@ -15,4 +19,5 @@ i2c0: i2c@80058000 {
reg = <0x80058000 2000>;
interrupts = <111 68>;
clock-frequency = <40>;
+ fsl,i2c-dma-channel = <6>;
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 832d30a..e4a4842 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -420,6 +420,7 @@
reg = <0x80058000 2000>;
interrupts = <111 68>;
clock-frequency = <40>;
+ fsl,i2c-dma-channel = <6>;
status = "disabled";
};
@@ -430,6 +431,7 @@
reg = <0x8005a000 2000>;
interrupts = <110 69>;
clock-frequency = <40>;
+ fsl,i2c-dma-channel = <7>;
status = "disabled";
};
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index 47a7e20..989d4f8 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -7,8 +7,6 @@
*
* Copyright (C) 2009-2010 Freescale Semiconductor, Inc. All Rights Reserved.
*
- * TODO: add dma-support if platform-support for it is available
- *
* 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
@@ -31,6 +29,9 @@
#include
#include
#include
+#include
+#include
+#include
#define DRIVER_NAME "mxs-i2c"
@@ -136,6 +137,16 @@ struct mxs_i2c_dev {
u32 cmd_err;
struct i2c_adapter adapter;
const struct mxs_i2c_speed_config *speed;
+
+ /* DMA support components */
+ booldma_mode;
+ int dma_channel;
+ struct dma_chan *dmach;
+ struct mxs_dma_data dma_data;
+ uint32_tpio_data[2];
+ uint32_taddr_data;
+ struct scatterlist sg_io[2];
+ booldma_read;
};
static void mxs_i2c_reset(struct mxs_i2c_dev *i2c)
@@ -147,7 +158,11 @@ static void mxs_i2c_reset(struct mxs_i2c_dev *i2c)
writel(i2c->speed->timing2, i2c->regs + MXS_I2C_TIMING2);
writel(MXS_I2C_IRQ_MASK << 8, i2c->regs + MXS_I2C_CTRL1_SET);
- writel(MXS_I2C_QUEUECTRL_PIO_QUEUE_MODE,
+ if (i2c->dma_mode)
+ writel(MXS_I2C_QUEUECTRL_PIO_QUEUE_MODE,
+ i2c->regs + MXS_I2C_QUEUECTRL_CLR);
+ else
+ writel(MXS_I2C_QUEUECTRL_PIO_QUEUE_MODE,
i2c->regs + MXS_I2C_QUEUECTRL_SET);
}
@@ -238,6 +253,150 @@ static int mxs_i2c_finish_read(struct mxs_i2c_dev *i2c,
u8 *buf, int len)
return 0;
}
+static void mxs_i2c_dma_finish(struct mxs_i2c_dev *i2c)
+{
+ if (i2c->dma_read) {
+ dma_unmap_sg(i2c->dev, &i2c->sg_io[0], 1, DMA_TO_DEVICE);
+ dma_unmap_sg(i2c->dev, &i2c->sg_io[1], 1, DMA_FROM_DEVICE);
+ } else {
+ dma_unmap_sg(i2c->dev, i2c->sg_io, 2, DMA_TO_DEVICE);
+ }
+}
+
+static void mxs_i2c_dma_irq_callback(void *param)
+{
+ struct mxs_i2c_dev *i2c = param;
+
+ complete(&i2c->cmd_complete);
+ mxs_i2c_dma_finish(i2c);
+
[PATCH 1/2 V2] MXS: Set I2C timing registers for mxs-i2c
This patch configures the I2C bus timing registers according
to information passed via DT. Currently, 100kHz and 400kHz
modes are supported.
The TIMING2 register value is wrong in the documentation for
i.MX28! This was found and fixed by:
Shawn Guo
Signed-off-by: Marek Vasut
Cc: Detlev Zundel
CC: Dong Aisheng
CC: Fabio Estevam
Cc: Linux ARM kernel
Cc: linux-i2c@vger.kernel.org
CC: Sascha Hauer
CC: Shawn Guo
Cc: Stefano Babic
CC: Uwe Kleine-König
Cc: Wolfgang Denk
Cc: Wolfram Sang
---
Documentation/devicetree/bindings/i2c/i2c-mxs.txt |2 +
arch/arm/boot/dts/imx28.dtsi |2 +
drivers/i2c/busses/i2c-mxs.c | 56 +
3 files changed, 60 insertions(+)
V2: (even though technically V, I really need to start doing this
patch management properly, it's quite a mess now)
Fixed static const struct mxs_i2c_speed_config ... pointed by Dong.
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
index 1bfc02d..2ed5332 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: Should be "fsl,-i2c"
- reg: Should contain registers location and length
- interrupts: Should contain ERROR and DMA interrupts
+- clock-frequency: desired I2C bus clock frequency in Hz.
Examples:
@@ -13,4 +14,5 @@ i2c0: i2c@80058000 {
compatible = "fsl,imx28-i2c";
reg = <0x80058000 2000>;
interrupts = <111 68>;
+ clock-frequency = <40>;
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index ee3778a..832d30a 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -419,6 +419,7 @@
compatible = "fsl,imx28-i2c";
reg = <0x80058000 2000>;
interrupts = <111 68>;
+ clock-frequency = <40>;
status = "disabled";
};
@@ -428,6 +429,7 @@
compatible = "fsl,imx28-i2c";
reg = <0x8005a000 2000>;
interrupts = <110 69>;
+ clock-frequency = <40>;
status = "disabled";
};
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index 04eb441..47a7e20 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -46,6 +46,10 @@
#define MXS_I2C_CTRL0_DIRECTION0x0001
#define MXS_I2C_CTRL0_XFER_COUNT(v)((v) & 0x)
+#define MXS_I2C_TIMING0(0x10)
+#define MXS_I2C_TIMING1(0x20)
+#define MXS_I2C_TIMING2(0x30)
+
#define MXS_I2C_CTRL1 (0x40)
#define MXS_I2C_CTRL1_SET (0x44)
#define MXS_I2C_CTRL1_CLR (0x48)
@@ -97,6 +101,25 @@
#define MXS_CMD_I2C_READ (MXS_I2C_CTRL0_SEND_NAK_ON_LAST | \
MXS_I2C_CTRL0_MASTER_MODE)
+struct mxs_i2c_speed_config {
+ uint32_ttiming0;
+ uint32_ttiming1;
+ uint32_ttiming2;
+};
+
+/* Timing values for the default 24MHz clock supplied into the i2c block. */
+static const struct mxs_i2c_speed_config mxs_i2c_95kHz_config = {
+ .timing0= 0x00780030,
+ .timing1= 0x00800030,
+ .timing2= 0x00300030,
+};
+
+static const struct mxs_i2c_speed_config mxs_i2c_400kHz_config = {
+ .timing0= 0x000f0007,
+ .timing1= 0x001f000f,
+ .timing2= 0x00300030,
+};
+
/**
* struct mxs_i2c_dev - per device, private MXS-I2C data
*
@@ -112,11 +135,17 @@ struct mxs_i2c_dev {
struct completion cmd_complete;
u32 cmd_err;
struct i2c_adapter adapter;
+ const struct mxs_i2c_speed_config *speed;
};
static void mxs_i2c_reset(struct mxs_i2c_dev *i2c)
{
stmp_reset_block(i2c->regs);
+
+ writel(i2c->speed->timing0, i2c->regs + MXS_I2C_TIMING0);
+ writel(i2c->speed->timing1, i2c->regs + MXS_I2C_TIMING1);
+ writel(i2c->speed->timing2, i2c->regs + MXS_I2C_TIMING2);
+
writel(MXS_I2C_IRQ_MASK << 8, i2c->regs + MXS_I2C_CTRL1_SET);
writel(MXS_I2C_QUEUECTRL_PIO_QUEUE_MODE,
i2c->regs + MXS_I2C_QUEUECTRL_SET);
@@ -319,6 +348,28 @@ static const struct i2c_algorithm mxs_i2c_algo = {
.functionality = mxs_i2c_func,
};
+static int mxs_i2c_get_ofdata(struct mxs_i2c_dev *i2c)
+{
+ uint32_t speed;
+ struct device *dev = i2c->dev;
+ struct device_node *node = dev->of_node;
+ int ret;
+
+ if (!node)
+ return -EINVAL;
+
+ i2c->speed = &mxs_i2c_95kHz_config;
+ ret = of_property_read_u32(node, "clock-frequency"
Re: Fwd: Hid over I2C and ACPI interaction
On Thu, Jul 05, 2012 at 03:01:57PM +0800, Zhang Rui wrote: > +Note that although these are ACPI devices, we prefer to use PnP drivers > for them, > +this is because: > +1. all the non-ACPI-predefined Devices are exported as PnP devices as > well > +2. PnP bus is a well designed bus. Probing via PnP layer saves a lot of > work > + for the device driver, e.g. getting & parsing ACPI resources. (Nice BKM, thanks for sharing) I have few questions about using PnP drivers instead of pure ACPI drivers. ACPI 5.0 defined some new resources, for example "Fixed DMA descriptor" that has information about the request line + channel for the device to use. Hovewer, PnP drivers pass resources as 'struct resource', which basically only has start and end - how do you represent all this new stuff using 'struct resource'? Or should we use acpi_walk_resources() where 'struct resource' is not suitable? -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c i.MX: Fix divider table
On Thu, Jul 05, 2012 at 06:01:53PM +0200, Sascha Hauer wrote: > On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > > Measurements on i.MX1 and i.MX53 have shown that the divider values > > > in the datasheets are wrong. the values from first, third and fourth > > > column were all measured to be 8 higher than in the datasheet. It > > > should be safe to assume that the SoCs between i.MX1 and i.MX53 behave > > > the same as the i2c unit is unchanged since the i.MX1. > > We may need to check with IC guys? Or you've done? > > I don't have contact to the IC guys. Could you do this? I'd be > interested in the results. Sure, but it may be slow, as you know, many people are in summer break. Thanks Richard > > Sascha > > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c i.MX: Fix divider table
On Thu, Jul 05, 2012 at 11:36:27PM +0530, Shubhrajyoti Datta wrote: > On Thu, Jul 5, 2012 at 6:40 PM, Sascha Hauer wrote: > > Measurements on i.MX1 and i.MX53 have shown that the divider values > > in the datasheets are wrong. > How were the measurements made? With an oscilloscope measuring the period length. This is probably not very exact, but the current values are way off. We had 350KHz instead of 380KHz (best possible divider) on an i.MX53. Funny enough some divider values really match the ones in the datasheet. BTW I'm pretty sure the input frequency to the core is calculated correctly as it's the same clock that also drives the timer. > > > the values from first, third and fourth > > column were all measured to be 8 higher than in the datasheet. It > > should be safe to assume that the SoCs between i.MX1 and i.MX53 behave > > the same as the i2c unit is unchanged since the i.MX1. > > Also does it vary board to board or is fixed by the ip? > What I mean is that the external cap etc. The clock is derived from an internal SoC clock, I don't think this can be influenced that much by external components. I did not test different boards, but two board with different SoCs. Let's see what the IC guys tell us. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On 7/5/2012 4:54 AM, Arnd Bergmann wrote:
On Thursday 05 July 2012, Sebastian Hesselbarth wrote:
Andrew,
is it possible to group all gpio banks into one DT description?
For mach-dove it could be something like:
gpio: gpio-controller {
compatible = "marvell, orion-gpio";
...
bank0@d0400 {
reg = <0xd0400 0x40>;
ngpio = <8>;
mask-offset = <0>;
interrupts = <12>;
};
bank1@d0400 {
reg = <0xd0400 0x40>;
ngpio = <8>;
mask-offset = <8>;
interrupts = <13>;
};
This way you have multiple nodes with the same register
and different names, which is not how it normally works.
The "mask-offset" property is really a "reg" in disguise.
"reg" is considerably more general than just "memory mapped
register address". It really means "any numeric identifier
that makes sense in the context of a parent device".
Therefore, one could say:
gpio: gpio-controller {
compatible = "marvell, orion-gpio";
reg = <0xd0400 0x40>;
#address-cells = <1>;
#size-cells = <0>;
...
bank0@0 {
reg = <0x0>;
ngpio = <8>;
mask-offset = <0>;
interrupts = <12>;
};
bank1@8 {
reg = <0x8>;
ngpio = <8>;
interrupts = <13>;
};
This would have the advantage that DT describes gpio-to-irq dependencies.
Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
gpios = <&gpio3 7 0>;
Is that desired?
The device tree representation should match what is in the data sheet
normally. If they are in a single continuous number range, then we should
probably have a single device node with multiple register ranges
rather than one device node for each 32-bit register. Looking at
arch/arm/plat-orion/gpio.c I think that is not actually the case though
and having separate banks is more logical.
Something completely different I just noticed in the original patch:
@@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct
irq_desc *desc)
}
}
+static int __initdata gpio0_irqs[4] = {
+ IRQ_DOVE_GPIO_0_7,
+ IRQ_DOVE_GPIO_8_15,
+ IRQ_DOVE_GPIO_16_23,
+ IRQ_DOVE_GPIO_24_31,
+};
+
+static int __initdata gpio1_irqs[4] = {
+ IRQ_DOVE_HIGH_GPIO,
+ 0,
+ 0,
+ 0,
+};
I think the latter one needs to be
+static int __initdata gpio1_irqs[4] = {
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+};
so we register all four parts to the same primary IRQ. The
same is true for the devicetree representation.
Arnd
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c i.MX: Fix divider table
On Thu, Jul 5, 2012 at 6:40 PM, Sascha Hauer wrote: > Measurements on i.MX1 and i.MX53 have shown that the divider values > in the datasheets are wrong. How were the measurements made? > the values from first, third and fourth > column were all measured to be 8 higher than in the datasheet. It > should be safe to assume that the SoCs between i.MX1 and i.MX53 behave > the same as the i2c unit is unchanged since the i.MX1. Also does it vary board to board or is fixed by the ip? What I mean is that the external cap etc. > > Signed-off-by: Sascha Hauer > --- -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Sebastian Hesselbarth writes: > On 07/05/2012 04:54 PM, Arnd Bergmann wrote: >> This way you have multiple nodes with the same register >> and different names, which is not how it normally works. > > Ok. > >>> This would have the advantage that DT describes gpio-to-irq dependencies. >>> Moreover, nodes that reference gpios can do gpios =<&gpio 71 0>; instead of >>> gpios =<&gpio3 7 0>; >> >> Is that desired? >> >> The device tree representation should match what is in the data sheet >> normally. If they are in a single continuous number range, then we should >> probably have a single device node with multiple register ranges >> rather than one device node for each 32-bit register. Looking at >> arch/arm/plat-orion/gpio.c I think that is not actually the case though >> and having separate banks is more logical. > > Well, looking at the datasheet of Dove GPIOs are numbered [63:0] plus > GPOs [71:64]. This dt will be a lot shorter and maybe it is describing > the hardware as it is. (Not sure about the syntax for irqs, though) They're numbered as [63:0] and [71:64] but they're on 3 different banks. iirc, there may even be some differences with the way the banks are dealing interrupts, so I don't see any reason to not represent the 3 banks in DT. Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
> Something completely different I just noticed in the original patch:
>
> > @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct
> > irq_desc *desc)
> > }
> > }
> >
> > +static int __initdata gpio0_irqs[4] = {
> > + IRQ_DOVE_GPIO_0_7,
> > + IRQ_DOVE_GPIO_8_15,
> > + IRQ_DOVE_GPIO_16_23,
> > + IRQ_DOVE_GPIO_24_31,
> > +};
> > +
> > +static int __initdata gpio1_irqs[4] = {
> > + IRQ_DOVE_HIGH_GPIO,
> > + 0,
> > + 0,
> > + 0,
> > +};
>
> I think the latter one needs to be
>
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> +};
>
> so we register all four parts to the same primary IRQ. The
> same is true for the devicetree representation.
Nope, does not work like that.
It does not matter which IRQ of a GPIO chip fires. It looks at the IRQ
cause bits for all lines and fires off the secondary ISR as needed for
the whole chip. So in effect, there is a mapping IRQ->GPIO chip, not
IRQ->1/4 of GPIO chip. With what you suggest above, you would end up
with four chained interrupt handlers, all being handled by the same
interrupt handler for one chio, and the last three in the chain would
never do anything since the first one does all the work.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c i.MX: Fix divider table
On Thu, Jul 05, 2012 at 10:52:39PM +0800, Richard Zhao wrote: > On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote: > > Measurements on i.MX1 and i.MX53 have shown that the divider values > > in the datasheets are wrong. the values from first, third and fourth > > column were all measured to be 8 higher than in the datasheet. It > > should be safe to assume that the SoCs between i.MX1 and i.MX53 behave > > the same as the i2c unit is unchanged since the i.MX1. > We may need to check with IC guys? Or you've done? I don't have contact to the IC guys. Could you do this? I'd be interested in the results. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On 07/05/2012 04:54 PM, Arnd Bergmann wrote:
This way you have multiple nodes with the same register
and different names, which is not how it normally works.
Ok.
This would have the advantage that DT describes gpio-to-irq dependencies.
Moreover, nodes that reference gpios can do gpios =<&gpio 71 0>; instead of
gpios =<&gpio3 7 0>;
Is that desired?
The device tree representation should match what is in the data sheet
normally. If they are in a single continuous number range, then we should
probably have a single device node with multiple register ranges
rather than one device node for each 32-bit register. Looking at
arch/arm/plat-orion/gpio.c I think that is not actually the case though
and having separate banks is more logical.
Well, looking at the datasheet of Dove GPIOs are numbered [63:0] plus
GPOs [71:64]. This dt will be a lot shorter and maybe it is describing
the hardware as it is. (Not sure about the syntax for irqs, though)
gpio@d0400 {
compatible = "marvell,orion-gpio";
gpio-controller;
reg = <0xd0400 0x20>, /* GPIO[31: 0] */
<0xd0420 0x20>, /* GPIO[63:32] */
<0xe8400 0x0c>; /* GPO [71:64] */
ngpio = <72>;
interrupts = <12 13 14 15>, <61>;
};
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On Thursday 05 July 2012, Sebastian Hesselbarth wrote:
> Andrew,
>
> is it possible to group all gpio banks into one DT description?
> For mach-dove it could be something like:
>
> gpio: gpio-controller {
> compatible = "marvell, orion-gpio";
> ...
>
> bank0@d0400 {
> reg = <0xd0400 0x40>;
> ngpio = <8>;
> mask-offset = <0>;
> interrupts = <12>;
> };
>
> bank1@d0400 {
> reg = <0xd0400 0x40>;
> ngpio = <8>;
> mask-offset = <8>;
> interrupts = <13>;
> };
This way you have multiple nodes with the same register
and different names, which is not how it normally works.
>
> This would have the advantage that DT describes gpio-to-irq dependencies.
> Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
> gpios = <&gpio3 7 0>;
Is that desired?
The device tree representation should match what is in the data sheet
normally. If they are in a single continuous number range, then we should
probably have a single device node with multiple register ranges
rather than one device node for each 32-bit register. Looking at
arch/arm/plat-orion/gpio.c I think that is not actually the case though
and having separate banks is more logical.
Something completely different I just noticed in the original patch:
> @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct
> irq_desc *desc)
> }
> }
>
> +static int __initdata gpio0_irqs[4] = {
> + IRQ_DOVE_GPIO_0_7,
> + IRQ_DOVE_GPIO_8_15,
> + IRQ_DOVE_GPIO_16_23,
> + IRQ_DOVE_GPIO_24_31,
> +};
> +
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + 0,
> + 0,
> + 0,
> +};
I think the latter one needs to be
+static int __initdata gpio1_irqs[4] = {
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+};
so we register all four parts to the same primary IRQ. The
same is true for the devicetree representation.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c i.MX: Fix divider table
On Thu, Jul 05, 2012 at 03:10:26PM +0200, Sascha Hauer wrote:
> Measurements on i.MX1 and i.MX53 have shown that the divider values
> in the datasheets are wrong. the values from first, third and fourth
> column were all measured to be 8 higher than in the datasheet. It
> should be safe to assume that the SoCs between i.MX1 and i.MX53 behave
> the same as the i2c unit is unchanged since the i.MX1.
We may need to check with IC guys? Or you've done?
Thanks
Richard
>
> Signed-off-by: Sascha Hauer
> ---
> drivers/i2c/busses/i2c-imx.c | 31 ++-
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 8d6b504..aabbe31 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -98,22 +98,27 @@
> * Document Number: MC9328MXLRM, Rev. 5.1, 06/2007
> *
> * Duplicated divider values removed from list
> + *
> + * These values (mostly) do not match the ones in the datasheet because
> + * measurements have shown that the values are wrong. This was tested
> + * on i.MX1 and i.MX53, so it shoud be safe to assume that the SoCs in
> + * between behave the same.
> */
>
> static u16 __initdata i2c_clk_div[50][2] = {
> - { 22, 0x20 }, { 24, 0x21 }, { 26, 0x22 }, { 28, 0x23 },
> - { 30, 0x00 }, { 32, 0x24 }, { 36, 0x25 }, { 40, 0x26 },
> - { 42, 0x03 }, { 44, 0x27 }, { 48, 0x28 }, { 52, 0x05 },
> - { 56, 0x29 }, { 60, 0x06 }, { 64, 0x2A }, { 72, 0x2B },
> - { 80, 0x2C }, { 88, 0x09 }, { 96, 0x2D }, { 104, 0x0A },
> - { 112, 0x2E }, { 128, 0x2F }, { 144, 0x0C }, { 160, 0x30 },
> - { 192, 0x31 }, { 224, 0x32 }, { 240, 0x0F }, { 256, 0x33 },
> - { 288, 0x10 }, { 320, 0x34 }, { 384, 0x35 }, { 448, 0x36 },
> - { 480, 0x13 }, { 512, 0x37 }, { 576, 0x14 }, { 640, 0x38 },
> - { 768, 0x39 }, { 896, 0x3A }, { 960, 0x17 }, { 1024, 0x3B },
> - { 1152, 0x18 }, { 1280, 0x3C }, { 1536, 0x3D }, { 1792, 0x3E },
> - { 1920, 0x1B }, { 2048, 0x3F }, { 2304, 0x1C }, { 2560, 0x1D },
> - { 3072, 0x1E }, { 3840, 0x1F }
> + { 30, 0x20 }, { 32, 0x21 }, { 34, 0x22 }, { 36, 0x23 },
> + { 38, 0x00 }, { 40, 0x24 }, { 44, 0x25 }, { 48, 0x26 },
> + { 50, 0x03 }, { 52, 0x27 }, { 56, 0x28 }, { 60, 0x05 },
> + { 64, 0x29 }, { 68, 0x06 }, { 72, 0x2A }, { 80, 0x2B },
> + { 88, 0x2C }, { 96, 0x09 }, { 104, 0x2D }, { 112, 0x0A },
> + { 120, 0x2E }, { 136, 0x2F }, { 152, 0x0C }, { 168, 0x30 },
> + { 200, 0x31 }, { 232, 0x32 }, { 248, 0x0F }, { 264, 0x33 },
> + { 288, 0x10 }, { 328, 0x34 }, { 392, 0x35 }, { 456, 0x36 },
> + { 480, 0x13 }, { 520, 0x37 }, { 576, 0x14 }, { 648, 0x38 },
> + { 776, 0x39 }, { 904, 0x3A }, { 960, 0x17 }, { 1032, 0x3B },
> + { 1152, 0x18 }, { 1288, 0x3C }, { 1544, 0x3D }, { 1800, 0x3E },
> + { 1920, 0x1B }, { 2048, 0x3F }, { 2304, 0x1C }, { 2560, 0x1D },
> + { 3072, 0x1E }, { 3840, 0x1F }
> };
>
> struct imx_i2c_struct {
> --
> 1.7.10
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8 v3] i2c: i801: enable irq for byte_by_byte transactions
Hi Daniel,
On Wed, 27 Jun 2012 21:54:15 +0800, Daniel Kurtz wrote:
> Byte-by-byte transactions are used primarily for accessing I2C devices
> with an SMBus controller. For these transactions, for each byte that is
> read or written, the SMBus controller generates a BYTE_DONE irq. The isr
> reads/writes the next byte, and clears the irq flag to start the next byte.
> On the penultimate irq, the isr also sets the LAST_BYTE flag.
>
> There is no locking around the cmd/len/count/data variables, since the
> I2C adapter lock ensures there is never multiple simultaneous transactions
> for the same device, and the driver thread never accesses these variables
> while interrupts might be occurring.
>
> The end result is faster I2C block read and write transactions.
>
> Note: This patch has only been tested and verified by doing I2C read and
> write block transfers on Cougar Point 6 Series PCH.
Two issues remaining:
> +static void i801_isr_byte_done(struct i801_priv *priv)
> +{
> + /* For SMBus block reads, length is first byte read */
> + if (priv->is_read && ((priv->cmd & 0x1c) == I801_BLOCK_DATA) &&
> + (priv->count == 0)) {
> + priv->len = inb_p(SMBHSTDAT0(priv));
> + if (priv->len < 1 || priv->len > I2C_SMBUS_BLOCK_MAX) {
> + dev_err(&priv->pci_dev->dev,
> + "Illegal SMBus block read size %d\n",
> + priv->len);
> + /* FIXME: Recover */
> + priv->len = I2C_SMBUS_BLOCK_MAX;
> + } else {
> + dev_dbg(&priv->pci_dev->dev,
> + "SMBus block read size is %d\n",
> + priv->len);
> + }
> + priv->data[-1] = priv->len;
> + } else if (priv->is_read) {
The "else" is wrong. When count == 0, you receive two bytes from the
controller: the block length in SMBHSTDAT0 and the first data byte in
SMBBLKDAT. So the code flow must fall through.
> + priv->data[priv->count++] = inb(SMBBLKDAT(priv));
This is lacking a boundary check. As I reported in an earlier review,
you shouldn't assume that the hardware will only emit the number of
interrupts you are expecting. If for any reason (crazy hardware or
driver bug) you get more interrupts than expected, you don't want to
overflow priv->data[].
> + /* Set LAST_BYTE for last byte of read transaction */
> + if (priv->count == priv->len - 1)
> + priv->cmd |= SMBHSTCNT_LAST_BYTE;
> + outb_p(priv->cmd, SMBHSTCNT(priv));
> + } else if (priv->count < priv->len - 1) {
> + /* Write next byte, except for IRQ after last byte */
> + outb_p(priv->data[++priv->count], SMBBLKDAT(priv));
> + outb_p(priv->cmd, SMBHSTCNT(priv));
> + }
> +
> + /* Clear BYTE_DONE to start next transaction. */
> + outb_p(SMBHSTSTS_BYTE_DONE, SMBHSTSTS(priv));
> +}
The rest looks OK.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On Thu, Jul 05, 2012 at 04:14:50PM +0200, Sebastian Hesselbarth wrote:
> On 07/05/2012 03:08 PM, Andrew Lunn wrote:
> >The issue is knowing what IRQ number to use for the secondary
> >interrupts.
> >
> >Orion use generic chip interrupts, both for the main interrupts and
> >the GPIO interrupts. This does not yet support irq domain, so i have
> >to layer a legacy domain on top. The legacy domain needs to know the
> >first IRQ and the number of IRQs. For the primary IRQs that is
> >easy. However, GPIO IRQ is not so easy, it depends on how many primary
> >IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> >64, and mv78xx0 has 96. I need to know this number when adding the
> >GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> >the orion_add_irq_domain() i have this number to hand. If i used to
> >entries in the match table, i would have to put this number into some
> >global variable, or somehow ask the IRQ subsystem what the next free
> >IRQ number is.
>
> Andrew,
>
> is it possible to group all gpio banks into one DT description?
Everything is possible.
I did think about having just one gpio controller, since as you said,
it makes it easier to describe gpios = <&gpio 71 0>; instead of gpios
= <&gpio3 7 0>; But most SoCs seem to have multiple GPIO controllers
in the .dtsi files. Only picoxcell has banks inside a single gpio
controller. So it would be a bit unusual.
What you suggest also adds a lot of complexity to the code and
probably means a lot less of the code can be shared with non-DT GPIO
handling code.
The natural size of a GPIO controller is 32 lines, not 8. The current
interrupt handling does not actually care which IRQ of a bank of 32
lines fired, it looks at all lines. The handler_data in the IRQ points
to the GPIO chip, not a subsection of the GPIO chip.
> bank5@e8400 {
> reg = <0xe8400 0x20>;
> ngpio = <8>;
> marvell,orion-gpio-output-only;
Some Orions mixed GPIOs GPOs and GPIs within one controller. So that
is not generic enough. Probably the pinmux DT description needs to be
able to specify per pin what a line can do.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On 07/05/2012 03:08 PM, Andrew Lunn wrote:
The issue is knowing what IRQ number to use for the secondary
interrupts.
Orion use generic chip interrupts, both for the main interrupts and
the GPIO interrupts. This does not yet support irq domain, so i have
to layer a legacy domain on top. The legacy domain needs to know the
first IRQ and the number of IRQs. For the primary IRQs that is
easy. However, GPIO IRQ is not so easy, it depends on how many primary
IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
64, and mv78xx0 has 96. I need to know this number when adding the
GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
the orion_add_irq_domain() i have this number to hand. If i used to
entries in the match table, i would have to put this number into some
global variable, or somehow ask the IRQ subsystem what the next free
IRQ number is.
Andrew,
is it possible to group all gpio banks into one DT description?
For mach-dove it could be something like:
gpio: gpio-controller {
compatible = "marvell, orion-gpio";
...
bank0@d0400 {
reg = <0xd0400 0x40>;
ngpio = <8>;
mask-offset = <0>;
interrupts = <12>;
};
bank1@d0400 {
reg = <0xd0400 0x40>;
ngpio = <8>;
mask-offset = <8>;
interrupts = <13>;
};
...
bank4@d0420 {
reg = <0xd0420 0x40>;
ngpio = <32>;
interrupts = <61>;
};
bank5@e8400 {
reg = <0xe8400 0x20>;
ngpio = <8>;
marvell,orion-gpio-output-only;
};
};
This would have the advantage that DT describes gpio-to-irq dependencies.
Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
gpios = <&gpio3 7 0>;
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" 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/4] mfd: support 88pm80x in 80x driver
On 07/05/2012 08:06 PM, Arnd Bergmann wrote:
On Thursday 05 July 2012, Qiao Zhou wrote:
+
+static const struct i2c_device_id pm80x_id_table[] = {
+ {"88PM800", CHIP_PM800},
+ {"88PM805", CHIP_PM805},
+};
+MODULE_DEVICE_TABLE(i2c, pm80x_id_table);
The point of moving the table to the individual drivers was that the
right one can get loaded automatically. This requires of course that
you put only one in there. It really needs to be
static const struct i2c_device_id pm800_id_table[] = {
{"88PM800", CHIP_PM800},
};
MODULE_DEVICE_TABLE(i2c, pm800_id_table);
and
static const struct i2c_device_id pm805_id_table[] = {
{"88PM805", CHIP_PM805},
};
MODULE_DEVICE_TABLE(i2c, pm805_id_table);
would update. thanks!
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 75f6ed6..22dba98 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -3,7 +3,12 @@
#
88pm860x-objs := 88pm860x-core.o 88pm860x-i2c.o
+88pm80x-objs := 88pm80x-i2c.o
+88pm800-objs := 88pm800-core.o
+88pm805-objs := 88pm805-core.o
obj-$(CONFIG_MFD_88PM860X)+= 88pm860x.o
+obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
+obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
This can be written much shorter if you leave out the "88pm80?-objs:=" lines
and just build each module from one file as in
obj-$(CONFIG_MFD_88PM800) += 88pm800-core.o 88pm80x-i2c.o
It might make sense to drop the "core" and "i2c" postfixes on the names,
your choice.
would update. thanks!
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
new file mode 100644
index 000..687f296
--- /dev/null
+++ b/include/linux/mfd/88pm80x.h
I don't really like repeating myself, but this still contains a lot
of crap that needs to be moved out of this file, into the places
where it's used:
+enum {
+ /* Procida */
+ PM800_CHIP_A0 = 0x60,
+ PM800_CHIP_A1 = 0x61,
+ PM800_CHIP_B0 = 0x62,
+ PM800_CHIP_C0 = 0x63,
+ PM800_CHIP_END = PM800_CHIP_C0,
+
+ /* Make sure to update this to the last stepping */
+ PM8XXX_CHIP_END = PM800_CHIP_END
+};
88pm800-core.c
would move to 88pm800.c
+enum {
+ PM800_ID_INVALID,
+ PM800_ID_VIBRATOR,
+ PM800_ID_SOUND,
+ PM800_ID_MAX,
+};
unused?
unused. would remove.
+enum {
+ PM800_ID_BUCK1 = 0,
+ PM800_ID_BUCK2,
+ PM800_ID_BUCK3,
+ PM800_ID_BUCK4,
+ PM800_ID_BUCK5,
+
+ PM800_ID_LDO1,
+ PM800_ID_LDO2,
+ PM800_ID_LDO3,
+ PM800_ID_LDO4,
+ PM800_ID_LDO5,
+ PM800_ID_LDO6,
+ PM800_ID_LDO7,
+ PM800_ID_LDO8,
+ PM800_ID_LDO9,
+ PM800_ID_LDO10,
+ PM800_ID_LDO11,
+ PM800_ID_LDO12,
+ PM800_ID_LDO13,
+ PM800_ID_LDO14,
+ PM800_ID_LDO15,
+ PM800_ID_LDO16,
+ PM800_ID_LDO17,
+ PM800_ID_LDO18,
+ PM800_ID_LDO19,
+
+ PM800_ID_RG_MAX,
+};
+#define PM800_MAX_REGULATORPM800_ID_RG_MAX /* 5 Bucks, 19 LDOs */
+#define PM800_NUM_BUCK (5) /*5 Bucks */
+#define PM800_NUM_LDO (19) /*19 Bucks */
unused? should probably go into the regulator driver
it's regulator resource and be used in 88pm800_core.c & regulator.c.
keep it here currently.
+/* 88PM805 Registers */
+#define PM805_CHIP_ID (0x00)
88pm805-core.c
would move it to 805-core.c
+/* Audio */
+
+/* 88PM800 registers */
+enum {
+ PM80X_INVALID_PAGE = 0,
+ PM80X_BASE_PAGE,
+ PM80X_POWER_PAGE,
+ PM80X_GPADC_PAGE,
+ PM80X_TEST_PAGE,
+};
unused?
unused and would remove
+/* page 0 basic: slave adder 0x60 */
+
+/* Interrupt Registers */
+#define PM800_CHIP_ID (0x00)
+
+#define PM800_STATUS_1 (0x01)
+#define PM800_ONKEY_STS1 (1 << 0)
+#define PM800_EXTON_STS1 (1 << 1)
+#define PM800_CHG_STS1 (1 << 2)
+#define PM800_BAT_STS1 (1 << 3)
+#define PM800_VBUS_STS1(1 << 4)
+#define PM800_LDO_PGOOD_STS1 (1 << 5)
+#define PM800_BUCK_PGOOD_STS1 (1 << 6)
+
+#define PM800_STATUS_2 (0x02)
+#define PM800_RTC_ALARM_STS2 (1 << 0)
These can probably stay here.
+#define PM800_INT_STATUS1 (0x05)
+#define PM800_ONKEY_INT_STS1 (1 << 0)
+#define PM800_EXTON_INT_STS1 (1 << 1)
+#define PM800_CHG_INT_STS1 (1 << 2)
+#define PM800_BAT_INT_STS1 (1 << 3)
+#define PM800_RTC_INT_STS1 (1 << 4)
+#define PM800_CLASSD_OC_INT_STS1 (1 << 5)
...
+/* number of INT_ENA & INT_STATUS regs */
+#define PM800_INT_REG_NUM (4)
all the interrupt handling can go into 88pm800-core.c
would move to pm800-core.c
+/* RTC Registers */
+#define PM800_RTC_CONTROL (0xD0)
+#define PM800_RTC_COUNTER1 (0xD1)
+#define PM800_RTC_COUNTER2 (0
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On Thursday 05 July 2012, Andrew Lunn wrote: > > > > I'm wondering about this one. The other platforms usually put the secondary > > interrupt controllers into the same match table, while you call > > orion_gpio_of_init > > from orion_add_irq_domain. Can you explain why you do this? Does it have > > any disadvantages? > > The issue is knowing what IRQ number to use for the secondary > interrupts. > > Orion use generic chip interrupts, both for the main interrupts and > the GPIO interrupts. This does not yet support irq domain, so i have > to layer a legacy domain on top. The legacy domain needs to know the > first IRQ and the number of IRQs. For the primary IRQs that is > easy. However, GPIO IRQ is not so easy, it depends on how many primary > IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood, > 64, and mv78xx0 has 96. I need to know this number when adding the > GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in > the orion_add_irq_domain() i have this number to hand. If i used to > entries in the match table, i would have to put this number into some > global variable, or somehow ask the IRQ subsystem what the next free > IRQ number is. But couldn't you store the number of interrupts for the primary controller in a local variable? I think the of_irq code already guarantees that the parent is probed first. > As for disadvantages, humm. Dove has yet more interrupts, from the > PMU. They are currently unsupported in DT. When we add support for the > PMU interrupt controller, we are going to have the same problem, what > IRQ base should it use. Either we extend the chaining, calling > dove_pmu_of_init from orion_gpio_of_init(), where we know the next > free IRQ. Or we find out how to ask the IRQ subsystem for the next > available. Better still, the work to make generic chip interrupts irq > domain aware would get completed, and we can swap all this code to irq > domain linear and this whole probable probably goes away. Yes, that makes sense. Using the linear domain should solve all these nicely. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Le Thu, 5 Jul 2012 15:15:22 +0200, Andrew Lunn a écrit : > > > The biggest problem i had, is the interaction between generic chip > > > interrupts and irqdomain. There has been work to integrate the two, > > > but its stalled. Either the work needs restarting and completing, or > > > you need to throw away the use of generic interrupt so that you can > > > use irqdomain linear. IMHO, throwing away generic interrupt is the > > > wrong way. > > > > Can you expand on why you think it would be wrong to throw away the > > usage of irq_chip_generic, compared to implementing directly an > > irq_chip? > > Basically you are asking, why should i use the framework when i can do > it by hand. Agreed :) > What are the advantages if ignoring the framework and doing it by > hand? Many GPIO drivers directly use irq_chip (though it's true some of them use irq_chip_generic), and the irq_chip_generic framework doesn't have really proper support for the other new irqdomain framework, so I was wondering what the best solution was. I found the proposal from Rob Herring to improve that situation, but apparently the conclusion from Grant Likely was "Let's discuss this at the next Connect". That patch set was posted in January, so two Linaro Connects happened since them, I don't know if progress has been made here. I guess I'll just stick to irq_chip_generic + irqdomain_legacy for now. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On Thu, Jul 05, 2012 at 02:58:01PM +0200, Thomas Petazzoni wrote: > Hello, > > Le Thu, 5 Jul 2012 11:48:24 +0200, > Andrew Lunn a ??crit : > > > The biggest problem i had, is the interaction between generic chip > > interrupts and irqdomain. There has been work to integrate the two, > > but its stalled. Either the work needs restarting and completing, or > > you need to throw away the use of generic interrupt so that you can > > use irqdomain linear. IMHO, throwing away generic interrupt is the > > wrong way. > > Can you expand on why you think it would be wrong to throw away the > usage of irq_chip_generic, compared to implementing directly an > irq_chip? Basically you are asking, why should i use the framework when i can do it by hand. What are the advantages if ignoring the framework and doing it by hand? Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c i.MX: Fix divider table
Measurements on i.MX1 and i.MX53 have shown that the divider values
in the datasheets are wrong. the values from first, third and fourth
column were all measured to be 8 higher than in the datasheet. It
should be safe to assume that the SoCs between i.MX1 and i.MX53 behave
the same as the i2c unit is unchanged since the i.MX1.
Signed-off-by: Sascha Hauer
---
drivers/i2c/busses/i2c-imx.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 8d6b504..aabbe31 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -98,22 +98,27 @@
* Document Number: MC9328MXLRM, Rev. 5.1, 06/2007
*
* Duplicated divider values removed from list
+ *
+ * These values (mostly) do not match the ones in the datasheet because
+ * measurements have shown that the values are wrong. This was tested
+ * on i.MX1 and i.MX53, so it shoud be safe to assume that the SoCs in
+ * between behave the same.
*/
static u16 __initdata i2c_clk_div[50][2] = {
- { 22, 0x20 }, { 24, 0x21 }, { 26, 0x22 }, { 28, 0x23 },
- { 30, 0x00 }, { 32, 0x24 }, { 36, 0x25 }, { 40, 0x26 },
- { 42, 0x03 }, { 44, 0x27 }, { 48, 0x28 }, { 52, 0x05 },
- { 56, 0x29 }, { 60, 0x06 }, { 64, 0x2A }, { 72, 0x2B },
- { 80, 0x2C }, { 88, 0x09 }, { 96, 0x2D }, { 104, 0x0A },
- { 112, 0x2E }, { 128, 0x2F }, { 144, 0x0C }, { 160, 0x30 },
- { 192, 0x31 }, { 224, 0x32 }, { 240, 0x0F }, { 256, 0x33 },
- { 288, 0x10 }, { 320, 0x34 }, { 384, 0x35 }, { 448, 0x36 },
- { 480, 0x13 }, { 512, 0x37 }, { 576, 0x14 }, { 640, 0x38 },
- { 768, 0x39 }, { 896, 0x3A }, { 960, 0x17 }, { 1024, 0x3B },
- { 1152, 0x18 }, { 1280, 0x3C }, { 1536, 0x3D }, { 1792, 0x3E },
- { 1920, 0x1B }, { 2048, 0x3F }, { 2304, 0x1C }, { 2560, 0x1D },
- { 3072, 0x1E }, { 3840, 0x1F }
+ { 30, 0x20 }, { 32, 0x21 }, { 34, 0x22 }, { 36, 0x23 },
+ { 38, 0x00 }, { 40, 0x24 }, { 44, 0x25 }, { 48, 0x26 },
+ { 50, 0x03 }, { 52, 0x27 }, { 56, 0x28 }, { 60, 0x05 },
+ { 64, 0x29 }, { 68, 0x06 }, { 72, 0x2A }, { 80, 0x2B },
+ { 88, 0x2C }, { 96, 0x09 }, { 104, 0x2D }, { 112, 0x0A },
+ { 120, 0x2E }, { 136, 0x2F }, { 152, 0x0C }, { 168, 0x30 },
+ { 200, 0x31 }, { 232, 0x32 }, { 248, 0x0F }, { 264, 0x33 },
+ { 288, 0x10 }, { 328, 0x34 }, { 392, 0x35 }, { 456, 0x36 },
+ { 480, 0x13 }, { 520, 0x37 }, { 576, 0x14 }, { 648, 0x38 },
+ { 776, 0x39 }, { 904, 0x3A }, { 960, 0x17 }, { 1032, 0x3B },
+ { 1152, 0x18 }, { 1288, 0x3C }, { 1544, 0x3D }, { 1800, 0x3E },
+ { 1920, 0x1B }, { 2048, 0x3F }, { 2304, 0x1C }, { 2560, 0x1D },
+ { 3072, 0x1E }, { 3840, 0x1F }
};
struct imx_i2c_struct {
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
> > +Required properties
> > +- compatible : Should be "marvell,orion-intc".
> > +- #interrupt-cells: Specifies the number of cells needed to encode an
> > + interrupt source. Supported value is <1>.
> > +- interrupt-controller : Declare this node to be an interrupt controller.
> > +- reg : Interrupt mask address.
>
> I think you should clarify that the "reg" property can be multiple
> 4-byte ranges, because that is fairly unusual.
O.K. The example is already like this, but i can add some more words.
> > +#ifdef CONFIG_OF
> > +static int __init orion_add_irq_domain(struct device_node *np,
> > + struct device_node *interrupt_parent)
> > +{
> > + int i = 0, irq_gpio;
> > + void __iomem *base;
> > +
> > + do {
> > + base = of_iomap(np, i);
> > + if (base) {
> > + orion_irq_init(i * 32, base);
> > + i++;
> > + }
> > + } while (base);
> > +
> > + irq_domain_add_legacy(np, i * 32, 0, 0,
> > + &irq_domain_simple_ops, NULL);
> > +
> > + irq_gpio = i * 32;
> > + orion_gpio_of_init(irq_gpio);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id orion_irq_match[] = {
> > + { .compatible = "marvell,orion-intc",
> > + .data = orion_add_irq_domain, },
> > + {},
> > +};
> > +
> > +void __init orion_dt_init_irq(void)
> > +{
> > + of_irq_init(orion_irq_match);
> > +}
> > +#endif
>
> I'm wondering about this one. The other platforms usually put the secondary
> interrupt controllers into the same match table, while you call
> orion_gpio_of_init
> from orion_add_irq_domain. Can you explain why you do this? Does it have
> any disadvantages?
The issue is knowing what IRQ number to use for the secondary
interrupts.
Orion use generic chip interrupts, both for the main interrupts and
the GPIO interrupts. This does not yet support irq domain, so i have
to layer a legacy domain on top. The legacy domain needs to know the
first IRQ and the number of IRQs. For the primary IRQs that is
easy. However, GPIO IRQ is not so easy, it depends on how many primary
IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
64, and mv78xx0 has 96. I need to know this number when adding the
GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
the orion_add_irq_domain() i have this number to hand. If i used to
entries in the match table, i would have to put this number into some
global variable, or somehow ask the IRQ subsystem what the next free
IRQ number is.
As for disadvantages, humm. Dove has yet more interrupts, from the
PMU. They are currently unsupported in DT. When we add support for the
PMU interrupt controller, we are going to have the same problem, what
IRQ base should it use. Either we extend the chaining, calling
dove_pmu_of_init from orion_gpio_of_init(), where we know the next
free IRQ. Or we find out how to ask the IRQ subsystem for the next
available. Better still, the work to make generic chip interrupts irq
domain aware would get completed, and we can swap all this code to irq
domain linear and this whole probable probably goes away.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Hello, Le Thu, 5 Jul 2012 11:48:24 +0200, Andrew Lunn a écrit : > The biggest problem i had, is the interaction between generic chip > interrupts and irqdomain. There has been work to integrate the two, > but its stalled. Either the work needs restarting and completing, or > you need to throw away the use of generic interrupt so that you can > use irqdomain linear. IMHO, throwing away generic interrupt is the > wrong way. Can you expand on why you think it would be wrong to throw away the usage of irq_chip_generic, compared to implementing directly an irq_chip? Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
- AM1808 based board
- 64 MiB DDR ram
- 2 MiB Nor flash
- 128 MiB NAND flash
- use internal RTC
- I2C support
- hwmon lm75 support
- UBI/UBIFS support
- MMC support
- USB OTG support
Signed-off-by: Heiko Schocher
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-...@lists.infradead.org
Cc: linux-i2c@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: David Woodhouse
Cc: Ben Dooks
Cc: Wolfram Sang
Cc: Sekhar Nori
Cc: Kevin Hilman
Cc: Wolfgang Denk
Cc: Scott Wood
Cc: Sylwester Nawrocki
---
- post this board support with USB support, even though
USB is only working with the 10 ms "workaround", posted here:
http://comments.gmane.org/gmane.linux.usb.general/54505
I see this issue also on the AM1808 TMDXEXP1808L evalboard.
- MMC and USB are not using OF support yet, ideas how to port
this are welcome. I need for USB and MMC boards board
specific callbacks, how to solve this with OF support?
- changes for v2:
- changes in the nand node due to comments from Scott Wood:
- add "ti,davinci-" prefix
- Dashes are preferred to underscores
- rename "nandflash" to "nand"
- introduce new "ti,davinci" specific properties for setting
up ecc_mode, ecc_bits, options and bbt options, instead
using linux defines
- changes for i2c due to comments from Sylwester Nawrocki:
- use "cell-index" instead "id"
- OF_DEV_AUXDATA in the machine code, instead pre-define
platform device name
- add comment from Grant Likely for i2c:
- removed "id" resp. "cell-index" completely
- fixed documentation
- use of_match_ptr()
- use devm_kzalloc() for allocating plattform data mem
- fixed a whitespace issue
- add net comments from Grant Likely:
- add prefix "ti,davinci-" to davinci specific property names
- remove version property
- use compatible name "ti,davinci-dm6460-emac"
- add comment from Grant Likely:
- rename compatible node
- do not use cell-index
- CONFIG_OF required for this board
TODO:
- create a generic board support file, as I got no
answer to my ping to grant, maybe this could be done
in a second step?
- changes for v3:
- add comments from Sergei Shtylyov:
- rename compatible" prop to "ti,cp_intc"
- cp_intc_init now used for Interrupt controller init
- changes for v4:
add comment from Nori Sekhar:
- rename davinci emac compatible property to "ti,davinci-dm6467-emac"
- remove "pinmux-handle" property as discussed here:
http://www.spinics.net/lists/arm-kernel/msg175701.html
with Nori Sekhar
- changes for v5:
add comments from Grant Likely:
- rename compatible" prop to "ti,cp-intc"
- changes for v6:
rework this patch, as patch
ARM: davinci: cp_intc: Add OF support for TI interrupt controller
was changed from Nori Sekhar on Jul 03, 2012; 9:16pm
Changes therefore in this patch:
Call of_irq_init() in the generic DT board file and not in the
interrupt controller code. See arch/arm/mach-at91/board-dt.c or
arch/arm/mach-omap2/board-generic.c for examples.
At this point the question raises, if we should rename this
board port from arch/arm/mach-davinci/enbw_cmc.c to
arch/arm/mach-davinci/board-dt.c ? Also the defconfig to
davinci_of_defconfig ... ? The USB and MMC callbacks are
currently board specific, but if other boards come in,
that could be easily adapted for their needs ...
arch/arm/boot/dts/enbw_cmc.dts | 183 +++
arch/arm/configs/enbw_cmc_defconfig | 126
arch/arm/mach-davinci/Kconfig |9 +
arch/arm/mach-davinci/Makefile |1 +
arch/arm/mach-davinci/board-enbw-cmc.c | 385 +++
arch/arm/mach-davinci/include/mach/uncompress.h |1 +
6 files changed, 705 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
create mode 100644 arch/arm/configs/enbw_cmc_defconfig
create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c
diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
new file mode 100644
index 000..32dc7a9
--- /dev/null
+++ b/arch/arm/boot/dts/enbw_cmc.dts
@@ -0,0 +1,183 @@
+/*
+ * Device Tree for the EnBW CMC plattform
+ *
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Heiko Schocher
+ *
+ * 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.
+ */
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "EnBW CMC";
+ compatible = "enbw,cmc";
+
+ aliases {
+ ethernet0 = ð0;
+ };
+
+ arm {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0xfffee000 0x0002>;
+ in
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On Tuesday 03 July 2012, Andrew Lunn wrote:
> Both IRQ and GPIO controllers can now be represented in DT. The IRQ
> controllers are setup first, and then the GPIO controllers. Interrupts
> for GPIO lines are placed directly after the main interrupts in the
> interrupt space.
Overall looks very good.
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> index 80b9a94..8927e10 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> @@ -38,3 +38,22 @@ Example:
> reg-names = "mux status", "mux mask";
> mrvl,intc-nr-irqs = <2>;
> };
> +
> +* Marvell Orion Interrupt controller
> +
> +Required properties
> +- compatible : Should be "marvell,orion-intc".
> +- #interrupt-cells: Specifies the number of cells needed to encode an
> + interrupt source. Supported value is <1>.
> +- interrupt-controller : Declare this node to be an interrupt controller.
> +- reg : Interrupt mask address.
I think you should clarify that the "reg" property can be multiple
4-byte ranges, because that is fairly unusual.
> +#ifdef CONFIG_OF
> +static int __init orion_add_irq_domain(struct device_node *np,
> +struct device_node *interrupt_parent)
> +{
> + int i = 0, irq_gpio;
> + void __iomem *base;
> +
> + do {
> + base = of_iomap(np, i);
> + if (base) {
> + orion_irq_init(i * 32, base);
> + i++;
> + }
> + } while (base);
> +
> + irq_domain_add_legacy(np, i * 32, 0, 0,
> + &irq_domain_simple_ops, NULL);
> +
> + irq_gpio = i * 32;
> + orion_gpio_of_init(irq_gpio);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id orion_irq_match[] = {
> + { .compatible = "marvell,orion-intc",
> + .data = orion_add_irq_domain, },
> + {},
> +};
> +
> +void __init orion_dt_init_irq(void)
> +{
> + of_irq_init(orion_irq_match);
> +}
> +#endif
I'm wondering about this one. The other platforms usually put the secondary
interrupt controllers into the same match table, while you call
orion_gpio_of_init
from orion_add_irq_domain. Can you explain why you do this? Does it have
any disadvantages?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On 07/05/2012 01:48 PM, Andrew Lunn wrote: >> Yes. I am not sure yet how to describe those in the DT, or even if it >> is actually useful to describe them. Wouldn't it be simpler to just >> leave to the user of the GPIO to use a GPIO that's appropriate for its >> usage, i.e not use a GPO when input is needed? > > We assume the hardware designer has got the basic hardware right. Its > not going to work otherwise. > > What we are trying to detect is a DT author making a typo, assigning a > gpio-key to a GPO pin, for example. The current MPP scheme will detect > this sort of error and issue a warning to the kernel logs. The output-only/non-interrupt gpios could be marked as such in DT. The common code should not install irqs if marked by e.g. "marvell,gpio-no-irq". The gpio driver already fails to set input direction on output-only pins. This could be marked by e.g. "marvell,gpio-output-only" in DT. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" 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/4] mfd: support 88pm80x in 80x driver
On Thursday 05 July 2012, Qiao Zhou wrote:
> +
> +static const struct i2c_device_id pm80x_id_table[] = {
> + {"88PM800", CHIP_PM800},
> + {"88PM805", CHIP_PM805},
> +};
> +MODULE_DEVICE_TABLE(i2c, pm80x_id_table);
The point of moving the table to the individual drivers was that the
right one can get loaded automatically. This requires of course that
you put only one in there. It really needs to be
static const struct i2c_device_id pm800_id_table[] = {
{"88PM800", CHIP_PM800},
};
MODULE_DEVICE_TABLE(i2c, pm800_id_table);
and
static const struct i2c_device_id pm805_id_table[] = {
{"88PM805", CHIP_PM805},
};
MODULE_DEVICE_TABLE(i2c, pm805_id_table);
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 75f6ed6..22dba98 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -3,7 +3,12 @@
> #
>
> 88pm860x-objs:= 88pm860x-core.o 88pm860x-i2c.o
> +88pm80x-objs := 88pm80x-i2c.o
> +88pm800-objs := 88pm800-core.o
> +88pm805-objs := 88pm805-core.o
> obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
> +obj-$(CONFIG_MFD_88PM800)+= 88pm800.o 88pm80x.o
> +obj-$(CONFIG_MFD_88PM805)+= 88pm805.o 88pm80x.o
This can be written much shorter if you leave out the "88pm80?-objs:=" lines
and just build each module from one file as in
obj-$(CONFIG_MFD_88PM800) += 88pm800-core.o 88pm80x-i2c.o
It might make sense to drop the "core" and "i2c" postfixes on the names,
your choice.
> diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
> new file mode 100644
> index 000..687f296
> --- /dev/null
> +++ b/include/linux/mfd/88pm80x.h
I don't really like repeating myself, but this still contains a lot
of crap that needs to be moved out of this file, into the places
where it's used:
> +enum {
> + /* Procida */
> + PM800_CHIP_A0 = 0x60,
> + PM800_CHIP_A1 = 0x61,
> + PM800_CHIP_B0 = 0x62,
> + PM800_CHIP_C0 = 0x63,
> + PM800_CHIP_END = PM800_CHIP_C0,
> +
> + /* Make sure to update this to the last stepping */
> + PM8XXX_CHIP_END = PM800_CHIP_END
> +};
88pm800-core.c
> +enum {
> + PM800_ID_INVALID,
> + PM800_ID_VIBRATOR,
> + PM800_ID_SOUND,
> + PM800_ID_MAX,
> +};
unused?
> +enum {
> + PM800_ID_BUCK1 = 0,
> + PM800_ID_BUCK2,
> + PM800_ID_BUCK3,
> + PM800_ID_BUCK4,
> + PM800_ID_BUCK5,
> +
> + PM800_ID_LDO1,
> + PM800_ID_LDO2,
> + PM800_ID_LDO3,
> + PM800_ID_LDO4,
> + PM800_ID_LDO5,
> + PM800_ID_LDO6,
> + PM800_ID_LDO7,
> + PM800_ID_LDO8,
> + PM800_ID_LDO9,
> + PM800_ID_LDO10,
> + PM800_ID_LDO11,
> + PM800_ID_LDO12,
> + PM800_ID_LDO13,
> + PM800_ID_LDO14,
> + PM800_ID_LDO15,
> + PM800_ID_LDO16,
> + PM800_ID_LDO17,
> + PM800_ID_LDO18,
> + PM800_ID_LDO19,
> +
> + PM800_ID_RG_MAX,
> +};
> +#define PM800_MAX_REGULATOR PM800_ID_RG_MAX /* 5 Bucks, 19 LDOs */
> +#define PM800_NUM_BUCK (5) /*5 Bucks */
> +#define PM800_NUM_LDO (19) /*19 Bucks */
unused? should probably go into the regulator driver
> +/* 88PM805 Registers */
> +#define PM805_CHIP_ID(0x00)
88pm805-core.c
> +/* Audio */
> +
> +/* 88PM800 registers */
> +enum {
> + PM80X_INVALID_PAGE = 0,
> + PM80X_BASE_PAGE,
> + PM80X_POWER_PAGE,
> + PM80X_GPADC_PAGE,
> + PM80X_TEST_PAGE,
> +};
unused?
> +/* page 0 basic: slave adder 0x60 */
> +
> +/* Interrupt Registers */
> +#define PM800_CHIP_ID(0x00)
> +
> +#define PM800_STATUS_1 (0x01)
> +#define PM800_ONKEY_STS1 (1 << 0)
> +#define PM800_EXTON_STS1 (1 << 1)
> +#define PM800_CHG_STS1 (1 << 2)
> +#define PM800_BAT_STS1 (1 << 3)
> +#define PM800_VBUS_STS1 (1 << 4)
> +#define PM800_LDO_PGOOD_STS1 (1 << 5)
> +#define PM800_BUCK_PGOOD_STS1(1 << 6)
> +
> +#define PM800_STATUS_2 (0x02)
> +#define PM800_RTC_ALARM_STS2 (1 << 0)
These can probably stay here.
> +#define PM800_INT_STATUS1(0x05)
> +#define PM800_ONKEY_INT_STS1 (1 << 0)
> +#define PM800_EXTON_INT_STS1 (1 << 1)
> +#define PM800_CHG_INT_STS1 (1 << 2)
> +#define PM800_BAT_INT_STS1 (1 << 3)
> +#define PM800_RTC_INT_STS1 (1 << 4)
> +#define PM800_CLASSD_OC_INT_STS1 (1 << 5)
> ...
> +/* number of INT_ENA & INT_STATUS regs */
> +#define PM800_INT_REG_NUM(4)
all the interrupt handling can go into 88pm800-core.c
> +/* RTC Registers */
> +#define PM800_RTC_CONTROL(0xD0)
> +#define PM800_RTC_COUNTER1 (0xD1)
> +#define PM800_RTC_COUNTER2 (0xD2)
> +#define PM800_RTC_COUNTER3 (0xD3)
> +#define PM800_RTC_COUNTER4 (0xD4)
> +#define PM800_RTC_EXPIRE1_1 (0xD5)
> +#define PM800_RTC_EXPIRE1_2 (0xD6)
> +#define
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Hi Thomas > Yes. I am not sure yet how to describe those in the DT, or even if it > is actually useful to describe them. Wouldn't it be simpler to just > leave to the user of the GPIO to use a GPIO that's appropriate for its > usage, i.e not use a GPO when input is needed? We assume the hardware designer has got the basic hardware right. Its not going to work otherwise. What we are trying to detect is a DT author making a typo, assigning a gpio-key to a GPO pin, for example. The current MPP scheme will detect this sort of error and issue a warning to the kernel logs. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Le Thu, 05 Jul 2012 12:38:51 +0200, Arnaud Patard (Rtp) a écrit : > > The MPP registers are identical on Armada XP/370 and 88F6281 (not sure > > which other SoC datasheet I should be checking). Basically, it's just a > > range of contiguous registers, with 4 bits per pin to select the > > function. > > iirc, other SoCs are similar. The small exception being dove I > guess. Dove has a 3rd gpo [the gpios are output only] bank but to be > used as gpio require that a special bit is set and it's for all gpios of > this bank. You'll find this bit in the "general mpp configuration > register" if you look at the datasheet. Ok, this is a bit trickier, but we can probably do something for it as well. > > So my pinmux driver should simply work as is for Orion as well. The > > only difference between platforms is the number of MPP pins that are > > available, but this number also varies between versions of Armada XP > > and Armada 370, so I already support this in the driver. > > Are there some output-only gpio on armada xp/370 like on kirkwood/dove ? Yes. I am not sure yet how to describe those in the DT, or even if it is actually useful to describe them. Wouldn't it be simpler to just leave to the user of the GPIO to use a GPIO that's appropriate for its usage, i.e not use a GPO when input is needed? Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] input: add onkey support to 88PM80X PMIC
add onkey support to MARVELL 88PM80X PMIC.
Signed-off-by: Qiao Zhou
---
drivers/input/misc/88pm80x_onkey.c | 190
drivers/input/misc/Kconfig | 10 ++
drivers/input/misc/Makefile|1 +
3 files changed, 201 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/88pm80x_onkey.c
diff --git a/drivers/input/misc/88pm80x_onkey.c
b/drivers/input/misc/88pm80x_onkey.c
new file mode 100644
index 000..b202448
--- /dev/null
+++ b/drivers/input/misc/88pm80x_onkey.c
@@ -0,0 +1,190 @@
+/*
+ * 88pm80x_onkey.c - Marvell 88PM80x ONKEY driver
+ *
+ * Copyright (C) 2012 Marvell International Ltd.
+ * Haojian Zhuang
+ * Qiao Zhou
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PM800_LONG_ONKEY_EN(1 << 0)
+#define PM800_LONG_KEY_DELAY (8) /* 1 .. 16 seconds */
+#define PM800_LONKEY_PRESS_TIME((PM800_LONG_KEY_DELAY-1) << 4)
+#define PM800_LONKEY_PRESS_TIME_MASK (0xF0)
+#define PM800_SW_PDOWN (1 << 5)
+
+struct pm80x_onkey_info {
+ struct input_dev *idev;
+ struct pm80x_chip *pm80x;
+ struct regmap *map;
+ int irq;
+};
+
+/* 88PM80x gives us an interrupt when ONKEY is held */
+static irqreturn_t pm80x_onkey_handler(int irq, void *data)
+{
+ struct pm80x_onkey_info *info = data;
+ int ret = 0;
+
+ regmap_read(info->map, PM800_STATUS_1, &ret);
+ ret &= PM800_ONKEY_STS1;
+
+ input_report_key(info->idev, KEY_POWER, ret);
+ input_sync(info->idev);
+
+ return IRQ_HANDLED;
+}
+
+#ifdef CONFIG_PM
+static int pm80x_onkey_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct pm80x_chip *chip = dev_get_drvdata(pdev->dev.parent);
+
+ if (device_may_wakeup(dev))
+ chip->wu_flag |= (1 << PM800_IRQ_ONKEY);
+
+ return 0;
+}
+
+static int pm80x_onkey_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct pm80x_chip *chip = dev_get_drvdata(pdev->dev.parent);
+
+ if (device_may_wakeup(dev))
+ chip->wu_flag &= ~(1 << PM800_IRQ_ONKEY);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(pm80x_onkey_pm_ops, pm80x_onkey_suspend,
+pm80x_onkey_resume);
+
+static int __devinit pm80x_onkey_probe(struct platform_device *pdev)
+{
+
+ void *chip = dev_get_drvdata(pdev->dev.parent);
+ struct pm80x_onkey_info *info;
+ int ret;
+
+ info =
+ devm_kzalloc(&pdev->dev, sizeof(struct pm80x_onkey_info),
+GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ info->pm80x = (struct pm80x_chip *)chip;
+
+ info->irq = platform_get_irq(pdev, 0);
+ if (info->irq < 0) {
+ dev_err(&pdev->dev, "No IRQ resource!\n");
+ return -EINVAL;
+ }
+
+ info->map = info->pm80x->regmap;
+ if (!info->map) {
+ dev_err(&pdev->dev, "no regmap!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ info->idev = input_allocate_device();
+ if (!info->idev) {
+ dev_err(&pdev->dev, "Failed to allocate input dev\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ info->idev->name = "88pm80x_on";
+ info->idev->phys = "88pm80x_on/input0";
+ info->idev->id.bustype = BUS_I2C;
+ info->idev->dev.parent = &pdev->dev;
+ info->idev->evbit[0] = BIT_MASK(EV_KEY);
+ info->idev->keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
+
+ ret = input_register_device(info->idev);
+ if (ret) {
+ dev_err(&pdev->dev, "Can't register input device: %d\n", ret);
+ goto out_reg;
+ }
+
+ ret = pm80x_request_irq(info->pm80x, info->irq, pm80x_onkey_handler,
+ IRQF_ONESHOT, "onkey", info);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to request IRQ: #%d: %d\n",
+ info->irq, ret);
+ goto out_irq;
+ }
+
+ platform_set_drvdata(pdev, info);
+
+ /* Enable long onkey detection */
+ regmap_update_bits(info->map, PM800_RTC_MISC4, PM
[PATCH 3/4] rtc: add rtc support to 88PM80X PMIC
add rtc driver for MARVELL 88PM80X PMIC and enable rtc function.
Signed-off-by: Qiao Zhou
---
drivers/rtc/Kconfig | 10 ++
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-88pm80x.c | 366 +
3 files changed, 377 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-88pm80x.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 08cbdb9..f3b49f8 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -135,6 +135,16 @@ config RTC_DRV_88PM860X
This driver can also be built as a module. If so, the module
will be called rtc-88pm860x.
+config RTC_DRV_88PM80X
+ tristate "Marvell 88PM80x"
+ depends on RTC_CLASS && I2C && MFD_88PM80X
+ help
+ If you say yes here you get support for RTC function in Marvell
+ 88PM80x chips.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-88pm80x.
+
config RTC_DRV_DS1307
tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 2973921..0d5b2b6 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -16,6 +16,7 @@ rtc-core-$(CONFIG_RTC_INTF_SYSFS) += rtc-sysfs.o
# Keep the list ordered.
obj-$(CONFIG_RTC_DRV_88PM860X) += rtc-88pm860x.o
+obj-$(CONFIG_RTC_DRV_88PM80X) += rtc-88pm80x.o
obj-$(CONFIG_RTC_DRV_AB3100) += rtc-ab3100.o
obj-$(CONFIG_RTC_DRV_AB8500) += rtc-ab8500.o
obj-$(CONFIG_RTC_DRV_AT32AP700X)+= rtc-at32ap700x.o
diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
new file mode 100644
index 000..d443157
--- /dev/null
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -0,0 +1,366 @@
+/*
+ * Real Time Clock driver for Marvell 88PM80x PMIC
+ *
+ * Copyright (c) 2012 Marvell International Ltd.
+ * Wenzeng Chen
+ * Qiao Zhou
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct pm80x_rtc_info {
+ struct pm80x_chip *chip;
+ struct regmap *map;
+ struct rtc_device *rtc_dev;
+ struct device *dev;
+ struct delayed_work calib_work;
+
+ int irq;
+ int vrtc;
+};
+
+static int pm80x_rtc_read_time(struct device *dev, struct rtc_time *tm);
+
+static irqreturn_t rtc_update_handler(int irq, void *data)
+{
+ struct pm80x_rtc_info *info = (struct pm80x_rtc_info *)data;
+ int mask;
+
+ mask = PM800_ALARM | PM800_ALARM_WAKEUP;
+ regmap_update_bits(info->map, PM800_RTC_CONTROL, mask | PM800_ALARM1_EN,
+ mask);
+ rtc_update_irq(info->rtc_dev, 1, RTC_AF);
+ return IRQ_HANDLED;
+}
+
+static int pm80x_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
+{
+ struct pm80x_rtc_info *info = dev_get_drvdata(dev);
+
+ if (enabled)
+ regmap_update_bits(info->map, PM800_RTC_CONTROL,
+ PM800_ALARM1_EN, PM800_ALARM1_EN);
+ else
+ regmap_update_bits(info->map, PM800_RTC_CONTROL,
+ PM800_ALARM1_EN, 0);
+ return 0;
+}
+
+/*
+ * Calculate the next alarm time given the requested alarm time mask
+ * and the current time.
+ */
+static void rtc_next_alarm_time(struct rtc_time *next, struct rtc_time *now,
+ struct rtc_time *alrm)
+{
+ unsigned long next_time;
+ unsigned long now_time;
+
+ next->tm_year = now->tm_year;
+ next->tm_mon = now->tm_mon;
+ next->tm_mday = now->tm_mday;
+ next->tm_hour = alrm->tm_hour;
+ next->tm_min = alrm->tm_min;
+ next->tm_sec = alrm->tm_sec;
+
+ rtc_tm_to_time(now, &now_time);
+ rtc_tm_to_time(next, &next_time);
+
+ if (next_time < now_time) {
+ /* Advance one day */
+ next_time += 60 * 60 * 24;
+ rtc_time_to_tm(next_time, next);
+ }
+}
+
+static int pm80x_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct pm80x_rtc_info *info = dev_get_drvdata(dev);
+ unsigned char buf[4];
+ unsigned long ticks, base, data;
+ regmap_raw_read(info->map, PM800_RTC_EXPIRE2_1, buf, 4);
+ base = (buf[3] << 24) | (buf[2] << 16) | (buf[1] << 8) | buf[0];
+ dev_dbg(info->dev, "%x-%x-%x-%x\n", buf
[PATCH 2/4] mfd: workaround: add companion chip in 88pm80x
in hw design, 800 is mainly for pmic control, while 805 for audio.
but there are 3 registers which controls class D speaker property,
and they are defined in 800 i2c client domain. so 805 codec driver
needs to use 800 i2c client to access class D speaker reg for
audio path management. so add this workaround for the purpose to
let 805 access 800 i2c in some scenario.
Signed-off-by: Qiao Zhou
---
drivers/mfd/88pm80x-i2c.c | 28
include/linux/mfd/88pm80x.h |1 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/88pm80x-i2c.c b/drivers/mfd/88pm80x-i2c.c
index 5fc0c9c..ecf93f0 100644
--- a/drivers/mfd/88pm80x-i2c.c
+++ b/drivers/mfd/88pm80x-i2c.c
@@ -19,6 +19,12 @@
#include
#include
+/*
+ * workaround: some registers needed by pm805 are defined in pm800, so
+ * need to use this global variable to maintain the relation between
+ * pm800 and pm805. would remove it after HW chip fixes the issue.
+ */
+static struct pm80x_chip *g_pm80x_chip;
const struct regmap_config pm80x_regmap_config = {
.reg_bits = 8,
@@ -62,6 +68,19 @@ int __devinit pm80x_init(struct i2c_client *client,
device_init_wakeup(&client->dev, 1);
+ /*
+* workaround: set g_pm80x_chip to the first probed chip. if the
+* second chip is probed, just point to the companion to each
+* other so that pm805 can access those specific register. would
+* remove it after HW chip fixes the issue.
+*/
+ if (!g_pm80x_chip)
+ g_pm80x_chip = chip;
+ else {
+ chip->companion = g_pm80x_chip->client;
+ g_pm80x_chip->companion = chip->client;
+ }
+
return 0;
err_chip_id:
@@ -76,6 +95,15 @@ int __devexit pm80x_deinit(struct i2c_client *client)
{
struct pm80x_chip *chip = i2c_get_clientdata(client);
+ /*
+* workaround: clear the dependency between pm800 and pm805.
+* would remove it after HW chip fixes the issue.
+*/
+ if (g_pm80x_chip->companion)
+ g_pm80x_chip->companion = NULL;
+ else
+ g_pm80x_chip = NULL;
+
regmap_exit(chip->regmap);
devm_kfree(&client->dev, chip);
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 687f296..6c91144 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -487,6 +487,7 @@ struct pm80x_chip {
struct pm80x_subchip *subchip;
struct device *dev;
struct i2c_client *client;
+ struct i2c_client *companion;
struct regmap *regmap;
struct regmap_irq_chip *regmap_irq_chip;
struct regmap_irq_chip_data *irq_data;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4 V3] add 88pm80x mfd driver
change log [v3->v2]: 1, dynamically get the irq_base, for both regmap_add_irq_chip and mfd_add_devices. add pm80x_request_irq & pm80x_free_irq for sub-driver facility, and modify related irq thread operation. remove irq_base member from 80x_chip & platform data. 2, split 88pm80x.o into 3 separate modules. 3, remove the 88pm80x r/w API, and directly use open-coded regmap api. 4, minor change: move pm80x_id_table from 80x-i2c.c to 800/805-core.c, exported pm80x_init, pm80x_deinit, and pm80x_bulk_read, add callback in pdata. change log [v2->v1]: 1, split 88pm80x-core.c into 88pm800-core.c and 88pm805.c, per Arnd's suggestion. after the re-arch, 88pm80x-i2c handles the 800 & 805 common parts, while 800-core.c & 805-core.c handle the specific parts in each chip. 2, add details about the workaround adding a i2c companion between 800 & 805, and make a separate patch for it, per Arnd's suggestion. 3, remove callback in pdata. but still keep the pdata currently. 4, only keep necessary register in 88pm80x.h, including registers for regulator/rtc/onkey/power/codec etc, and remove other registers from global visibility. 5, exported r/w API which requires regmap handle. as currently the pm800 chip has 3 i2c device, only passing a pm80x_chip info can't ensure r/w the register in correct i2c device. change log [v1]: 1, pm800 and pm805 are decoupled and probed separately; 2, re-used the most of API for pm800 and pm805 per Arnd's comments; 3, use regmap_irq, instead of previous 88pm80x_irq_data per Mark's comments. use regmap_add_irq_chip, and remove previous 88pm80x irq handling. 4, remove callback function in rtc pdata per Arnd's comments. 5, updated some coding style issue. Qiao Zhou (4): mfd: support 88pm80x in 80x driver mfd: workaround: add companion chip in 88pm80x rtc: add rtc support to 88PM80X PMIC input: add onkey support to 88PM80X PMIC drivers/input/misc/88pm80x_onkey.c | 190 + drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile|1 + drivers/mfd/88pm800-core.c | 499 + drivers/mfd/88pm805-core.c | 282 +++ drivers/mfd/88pm80x-i2c.c | 145 ++ drivers/mfd/Kconfig| 24 ++ drivers/mfd/Makefile |5 + drivers/rtc/Kconfig| 10 + drivers/rtc/Makefile |1 + drivers/rtc/rtc-88pm80x.c | 366 include/linux/mfd/88pm80x.h| 534 12 files changed, 2067 insertions(+), 0 deletions(-) create mode 100644 drivers/input/misc/88pm80x_onkey.c create mode 100644 drivers/mfd/88pm800-core.c create mode 100644 drivers/mfd/88pm805-core.c create mode 100644 drivers/mfd/88pm80x-i2c.c create mode 100644 drivers/rtc/rtc-88pm80x.c create mode 100644 include/linux/mfd/88pm80x.h -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] mfd: support 88pm80x in 80x driver
88PM800 and 88PM805 are two discrete chips used for power management.
Hardware designer can use them together or only one of them according
to requirement.
88pm80x_i2c.c provides common i2c driver handling for both 800 and
805, such as i2c_driver init, regmap init, read/write api etc.
88pm800_core.c handles specifically for 800, such as chip init, irq
init/handle, mfd device register, including rtc, onkey, regulator(
to be add later) etc. besides that, 800 has three i2c device, one
regular i2c client, two other i2c dummy for gpadc and power purpose.
88pm805_core.c handles specifically for 805, such as chip init, irq
init/handle, mfd device register, including codec, headset/mic detect
etc.
the i2c operation of both 800 and 805 are via regmap, and 88pm80x-i2c
exported a group of r/w bulk r/w and bits set API for facility.
Signed-off-by: Qiao Zhou
---
drivers/mfd/88pm800-core.c | 499
drivers/mfd/88pm805-core.c | 282 +++
drivers/mfd/88pm80x-i2c.c | 117 ++
drivers/mfd/Kconfig | 24 ++
drivers/mfd/Makefile|5 +
include/linux/mfd/88pm80x.h | 533 +++
6 files changed, 1460 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/88pm800-core.c
create mode 100644 drivers/mfd/88pm805-core.c
create mode 100644 drivers/mfd/88pm80x-i2c.c
create mode 100644 include/linux/mfd/88pm80x.h
diff --git a/drivers/mfd/88pm800-core.c b/drivers/mfd/88pm800-core.c
new file mode 100644
index 000..6a65ab2
--- /dev/null
+++ b/drivers/mfd/88pm800-core.c
@@ -0,0 +1,499 @@
+/*
+ * Base driver for Marvell 88PM800
+ *
+ * Copyright (C) 2012 Marvell International Ltd.
+ * Haojian Zhuang
+ * Joseph(Yossi) Hanin
+ * Qiao Zhou
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static const struct i2c_device_id pm80x_id_table[] = {
+ {"88PM800", CHIP_PM800},
+ {"88PM805", CHIP_PM805},
+};
+MODULE_DEVICE_TABLE(i2c, pm80x_id_table);
+
+static struct resource rtc_resources[] = {
+ {
+.name = "88pm80x-rtc",
+.start = PM800_IRQ_RTC,
+.end = PM800_IRQ_RTC,
+.flags = IORESOURCE_IRQ,
+},
+};
+
+static struct mfd_cell rtc_devs[] = {
+ {
+.name = "88pm80x-rtc",
+.num_resources = ARRAY_SIZE(rtc_resources),
+.resources = &rtc_resources[0],
+.id = -1,
+},
+};
+
+static struct resource onkey_resources[] = {
+ {
+.name = "88pm80x-onkey",
+.start = PM800_IRQ_ONKEY,
+.end = PM800_IRQ_ONKEY,
+.flags = IORESOURCE_IRQ,
+},
+};
+
+static struct mfd_cell onkey_devs[] = {
+ {
+.name = "88pm80x-onkey",
+.num_resources = 1,
+.resources = &onkey_resources[0],
+.id = -1,
+},
+};
+
+static const struct regmap_irq pm800_irqs[] = {
+ /* INT0 */
+ [PM800_IRQ_ONKEY] = {
+ .mask = PM800_ONKEY_INT_ENA1,
+ },
+ [PM800_IRQ_EXTON] = {
+ .mask = PM800_EXTON_INT_ENA1,
+ },
+ [PM800_IRQ_CHG] = {
+ .mask = PM800_CHG_INT_ENA1,
+ },
+ [PM800_IRQ_BAT] = {
+ .mask = PM800_BAT_INT_ENA1,
+ },
+ [PM800_IRQ_RTC] = {
+ .mask = PM800_RTC_INT_ENA1,
+ },
+ [PM800_IRQ_CLASSD] = {
+ .mask = PM800_CLASSD_OC_INT_ENA1,
+ },
+ /* INT1 */
+ [PM800_IRQ_VBAT] = {
+ .reg_offset = 1,
+ .mask = PM800_VBAT_INT_ENA2,
+ },
+ [PM800_IRQ_VSYS] = {
+ .reg_offset = 1,
+ .mask = PM800_VSYS_INT_ENA2,
+ },
+ [PM800_IRQ_VCHG] = {
+ .reg_offset = 1,
+ .mask = PM800_VCHG_INT_ENA2,
+ },
+ [PM800_IRQ_TINT] = {
+ .reg_offset = 1,
+ .mask = PM800_TINT_INT_ENA2,
+ },
+ /* INT2 */
+ [PM800_IRQ_GPADC0] = {
+ .reg_offset = 2,
+ .mask = PM800_GPADC0_INT_ENA3,
+ },
+ [PM800_IRQ_GPADC1] = {
+ .reg_offset = 2,
+ .mask = PM800_GPADC1_INT_ENA3,
+ },
+ [PM800_IRQ_GPADC2] = {
+ .reg_offset = 2,
+ .mask = PM800_GPADC2_INT_ENA3,
+ },
+ [PM
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Thomas Petazzoni writes: > Le Thu, 05 Jul 2012 12:11:40 +0200, > Arnaud Patard (Rtp) a écrit : > >> > You are not the only one working in this area. Arnaud Patard said he >> > was look at this as well. >> >> yeah, but tbh I've not made anything yet. If Thomas has already some >> code for it, we should try to make it "generic" so as to use it on >> armada xp and orion platforms. > > The MPP registers are identical on Armada XP/370 and 88F6281 (not sure > which other SoC datasheet I should be checking). Basically, it's just a > range of contiguous registers, with 4 bits per pin to select the > function. iirc, other SoCs are similar. The small exception being dove I guess. Dove has a 3rd gpo [the gpios are output only] bank but to be used as gpio require that a special bit is set and it's for all gpios of this bank. You'll find this bit in the "general mpp configuration register" if you look at the datasheet. > > So my pinmux driver should simply work as is for Orion as well. The > only difference between platforms is the number of MPP pins that are > available, but this number also varies between versions of Armada XP > and Armada 370, so I already support this in the driver. > Are there some output-only gpio on armada xp/370 like on kirkwood/dove ? Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8 v3] i2c: i801: enable irq for i801 smbus transactions
On Thu, 5 Jul 2012 10:10:15 +0200, Jean Delvare wrote: > On Thu, 5 Jul 2012 12:31:11 +0800, Daniel Kurtz wrote: > > On Thu, Jul 5, 2012 at 4:16 AM, Jean Delvare wrote: > > > Implementing 1* has the drawback of limiting interrupt support to ICH5 > > > and later chips, but I suspect it is the easiest and safest way, so I > > > have no objection if you want to do that. > > > > Let's do this first, and then refactor later to add support for > > pre-ICH5 parts, if needed. > > OK, fine with me. The only downside is that it excludes my > heavily-shared IRQ test machine, so testing that the shared IRQ case is > properly covered will be a little harder. Actually, no problem there: I can reproduce the issue just fine on my ICH5 system, which shares an IRQ between the sound chip and the SMBus controller. So I can use that system to test the updated code too. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
> I've looked at the datasheet for the 88F6281, and the GPIO registers > look fairly similar with Armada 370/XP, except that: > > * On 88F6281, there are two GPIO banks, while on Armada 370/XP it's a >continuous range of registers that control the GPIOs. But it can be >assimilated as one bank handling more than 32 GPIOs. So shouldn't be >a big problem to handle. The number of banks varies. Orion5x has one, Dove has three, etc. > > * The Armada 370/XP have additional set/clear registers that allow to >modify the GPIO states without having to do a read/mask/write >sequence, which is nicer on SMP. I guess we can handle that as a >variant inside the driver without too much problem. > > Marvell has given me a 88F6282 eval board, so I guess they are fine > with me spending some time ensuring that the new code works properly on > the previous platforms, especially in this case where the amount of > work does not seem to be enormous to keep the compatibility. That is good to hear. Thanks Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Andrew Lunn writes: Hi, > On Thu, Jul 05, 2012 at 11:02:51AM +0200, Thomas Petazzoni wrote: >> Hello Andrew, >> >> Le Tue, 3 Jul 2012 16:22:34 +0200, >> Andrew Lunn a ??crit : >> >> > Both IRQ and GPIO controllers can now be represented in DT. The IRQ >> > controllers are setup first, and then the GPIO controllers. Interrupts >> > for GPIO lines are placed directly after the main interrupts in the >> > interrupt space. >> > >> > Signed-off-by: Andrew Lunn >> >> I have started working on a pinctrl driver for mvebu, which would >> handle pin muxing (MPP) + gpio + gpio interrupts. > > Hi Thomas > > You are not the only one working in this area. Arnaud Patard said he > was look at this as well. yeah, but tbh I've not made anything yet. If Thomas has already some code for it, we should try to make it "generic" so as to use it on armada xp and orion platforms. > >> So far, the pin muxing part is working (needs some polishing, but the >> foundation is here), with device tree bindings. I think the pin muxing >> could be used for Orion as well. > > Great. This is one of the big things which we are missing when moving > a system over the DT. Being able to describe this in DT in a > standardized way is very much welcome. > >> Now, I'm planning to start working on the gpio + gpio interrupts parts >> of the driver, and I'm wondering how to interact with your work on the >> matter. > > I've publicly said, what i have is enough to get it working, but i > know its not the end solution. What i have is enough that gpio-key, > gpio-led, as described in DT, works. Boards can start using these and > as far as i can tell, the binding should not need to change. The GPIO > controller binding should also be sufficiently generic that it should > also not need changes when we replace the driver with pinctrl. > > The biggest problem i had, is the interaction between generic chip > interrupts and irqdomain. There has been work to integrate the two, > but its stalled. Either the work needs restarting and completing, or > you need to throw away the use of generic interrupt so that you can > use irqdomain linear. IMHO, throwing away generic interrupt is the > wrong way. > > The other thing you need to keep in mind is the namespace issues > between normal interrupts and GPIO interrupts. The way my patch works > is that normal interrupts are setup first, counting how many have been > created. Then GPIO interrupts are added, starting off where the normal > interrupts ended. Since 370/XP uses different interrupt code, you need > to think how to solve this issue. > >> My understanding is that the new way of doing a pinmux+gpio >> driver is to implement it in drivers/pinctrl/, which I have started >> doing. > > Great. > >> Should I continue working on a drivers/pinctrl/ driver for mvebu for >> Armada 370/XP, and then we see together if it makes sense to extend to >> Orion, and if so, what changes are needed? > > I know Marvell has contracted you to port to Armada 370/XP, not mvebu, > aka all chips which might be able to share this code. This IMHO is > wrong. So i personally would put the kirkwood and the Armada 370/XP > data sheets next to each other, and from the beginning on write the > driver so it supports them all. This assumes the ASIC engineers have > not radically changed anything... Please also try to stick to the DT > binding i've used. agreed. it should be written with all platforms in mind, as long as they're compatible. It can only make things better imho. Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Le Thu, 05 Jul 2012 12:11:40 +0200, Arnaud Patard (Rtp) a écrit : > > You are not the only one working in this area. Arnaud Patard said he > > was look at this as well. > > yeah, but tbh I've not made anything yet. If Thomas has already some > code for it, we should try to make it "generic" so as to use it on > armada xp and orion platforms. The MPP registers are identical on Armada XP/370 and 88F6281 (not sure which other SoC datasheet I should be checking). Basically, it's just a range of contiguous registers, with 4 bits per pin to select the function. So my pinmux driver should simply work as is for Orion as well. The only difference between platforms is the number of MPP pins that are available, but this number also varies between versions of Armada XP and Armada 370, so I already support this in the driver. However, using the pinmux driver will require changes in the device drivers, so that they request the pinmux for their devices. > > I know Marvell has contracted you to port to Armada 370/XP, not mvebu, > > aka all chips which might be able to share this code. This IMHO is > > wrong. So i personally would put the kirkwood and the Armada 370/XP > > data sheets next to each other, and from the beginning on write the > > driver so it supports them all. This assumes the ASIC engineers have > > not radically changed anything... Please also try to stick to the DT > > binding i've used. > > agreed. it should be written with all platforms in mind, as long as > they're compatible. It can only make things better imho. Certainly, especially for MPP/GPIO that are definitely very similar. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Hello,
Le Thu, 5 Jul 2012 11:48:24 +0200,
Andrew Lunn a écrit :
> Hi Thomas
>
> You are not the only one working in this area. Arnaud Patard said he
> was look at this as well.
Ok, I added Arnaud in the Cc list. Arnaud, what is the status of you
work?
> > So far, the pin muxing part is working (needs some polishing, but the
> > foundation is here), with device tree bindings. I think the pin muxing
> > could be used for Orion as well.
>
> Great. This is one of the big things which we are missing when moving
> a system over the DT. Being able to describe this in DT in a
> standardized way is very much welcome.
For the DT binding, I took my inspiration from the MXS and Samsung
pinctrl drivers, as those platforms also have independent pin muxing
(while some platforms such as Tegra, have hardware pin groups).
The .dtsi side looks like:
pinctrl@d0018000 {
compatible = "marvell,mv78230-pinmux";
reg = <0xd0018000 0x38>;
uart_2: uart-2 {
marvell,pins = <42 43>;
marvell,pins-function = <1>;
};
uart_3: uart-3 {
marvell,pins = <44 45>;
marvell,pins-function = <2>;
};
uart_0_control: uart-0-control {
marvell,pins = <42 43>;
marvell,pins-function = <2>;
};
uart_1_control: uart-1-control {
marvell,pins = <46 47>;
marvell,pins-function = <2>;
};
uart_2_control: uart-2-control {
marvell,pins = <44 45>;
marvell,pins-function = <1>;
};
uart_3_control: uart-3-control {
marvell,pins = <46 47>;
marvell,pins-function = <1>;
};
};
This defines the various pin muxing options, and then when
instantiating a device, you do:
test@12 {
compatible = "marvell,testdrv";
pinctrl-names = "default";
pinctrl-0 = <&uart_0_control>;
};
(This is with a dummy test driver that I'm using for testing). Then
the driver can use the pinctrl API to get the proper muxing for its
pins.
> > Now, I'm planning to start working on the gpio + gpio interrupts parts
> > of the driver, and I'm wondering how to interact with your work on the
> > matter.
>
> I've publicly said, what i have is enough to get it working, but i
> know its not the end solution. What i have is enough that gpio-key,
> gpio-led, as described in DT, works. Boards can start using these and
> as far as i can tell, the binding should not need to change. The GPIO
> controller binding should also be sufficiently generic that it should
> also not need changes when we replace the driver with pinctrl.
>
> The biggest problem i had, is the interaction between generic chip
> interrupts and irqdomain. There has been work to integrate the two,
> but its stalled. Either the work needs restarting and completing, or
> you need to throw away the use of generic interrupt so that you can
> use irqdomain linear. IMHO, throwing away generic interrupt is the
> wrong way.
>
> The other thing you need to keep in mind is the namespace issues
> between normal interrupts and GPIO interrupts. The way my patch works
> is that normal interrupts are setup first, counting how many have been
> created. Then GPIO interrupts are added, starting off where the normal
> interrupts ended. Since 370/XP uses different interrupt code, you need
> to think how to solve this issue.
Ok, thanks for those hints.
> > Should I continue working on a drivers/pinctrl/ driver for mvebu for
> > Armada 370/XP, and then we see together if it makes sense to extend to
> > Orion, and if so, what changes are needed?
>
> I know Marvell has contracted you to port to Armada 370/XP, not mvebu,
> aka all chips which might be able to share this code. This IMHO is
> wrong. So i personally would put the kirkwood and the Armada 370/XP
> data sheets next to each other, and from the beginning on write the
> driver so it supports them all. This assumes the ASIC engineers have
> not radically changed anything... Please also try to stick to the DT
> binding i've used.
I've looked at the datasheet for the 88F6281, and the GPIO registers
look fairly similar with A
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On Thu, Jul 05, 2012 at 11:02:51AM +0200, Thomas Petazzoni wrote: > Hello Andrew, > > Le Tue, 3 Jul 2012 16:22:34 +0200, > Andrew Lunn a ??crit : > > > Both IRQ and GPIO controllers can now be represented in DT. The IRQ > > controllers are setup first, and then the GPIO controllers. Interrupts > > for GPIO lines are placed directly after the main interrupts in the > > interrupt space. > > > > Signed-off-by: Andrew Lunn > > I have started working on a pinctrl driver for mvebu, which would > handle pin muxing (MPP) + gpio + gpio interrupts. Hi Thomas You are not the only one working in this area. Arnaud Patard said he was look at this as well. > So far, the pin muxing part is working (needs some polishing, but the > foundation is here), with device tree bindings. I think the pin muxing > could be used for Orion as well. Great. This is one of the big things which we are missing when moving a system over the DT. Being able to describe this in DT in a standardized way is very much welcome. > Now, I'm planning to start working on the gpio + gpio interrupts parts > of the driver, and I'm wondering how to interact with your work on the > matter. I've publicly said, what i have is enough to get it working, but i know its not the end solution. What i have is enough that gpio-key, gpio-led, as described in DT, works. Boards can start using these and as far as i can tell, the binding should not need to change. The GPIO controller binding should also be sufficiently generic that it should also not need changes when we replace the driver with pinctrl. The biggest problem i had, is the interaction between generic chip interrupts and irqdomain. There has been work to integrate the two, but its stalled. Either the work needs restarting and completing, or you need to throw away the use of generic interrupt so that you can use irqdomain linear. IMHO, throwing away generic interrupt is the wrong way. The other thing you need to keep in mind is the namespace issues between normal interrupts and GPIO interrupts. The way my patch works is that normal interrupts are setup first, counting how many have been created. Then GPIO interrupts are added, starting off where the normal interrupts ended. Since 370/XP uses different interrupt code, you need to think how to solve this issue. > My understanding is that the new way of doing a pinmux+gpio > driver is to implement it in drivers/pinctrl/, which I have started > doing. Great. > Should I continue working on a drivers/pinctrl/ driver for mvebu for > Armada 370/XP, and then we see together if it makes sense to extend to > Orion, and if so, what changes are needed? I know Marvell has contracted you to port to Armada 370/XP, not mvebu, aka all chips which might be able to share this code. This IMHO is wrong. So i personally would put the kirkwood and the Armada 370/XP data sheets next to each other, and from the beginning on write the driver so it supports them all. This assumes the ASIC engineers have not radically changed anything... Please also try to stick to the DT binding i've used. If however, you have to focus solely on Armada 370/XP, then the community can work on making your code generic at a late date. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
Hello Andrew, Le Tue, 3 Jul 2012 16:22:34 +0200, Andrew Lunn a écrit : > Both IRQ and GPIO controllers can now be represented in DT. The IRQ > controllers are setup first, and then the GPIO controllers. Interrupts > for GPIO lines are placed directly after the main interrupts in the > interrupt space. > > Signed-off-by: Andrew Lunn I have started working on a pinctrl driver for mvebu, which would handle pin muxing (MPP) + gpio + gpio interrupts. So far, the pin muxing part is working (needs some polishing, but the foundation is here), with device tree bindings. I think the pin muxing could be used for Orion as well. Now, I'm planning to start working on the gpio + gpio interrupts parts of the driver, and I'm wondering how to interact with your work on the matter. My understanding is that the new way of doing a pinmux+gpio driver is to implement it in drivers/pinctrl/, which I have started doing. Should I continue working on a drivers/pinctrl/ driver for mvebu for Armada 370/XP, and then we see together if it makes sense to extend to Orion, and if so, what changes are needed? Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Hid over I2C and ACPI interaction
Hi,
Many thanks for these information. It seems like I was on the right
track, but I didn't saw the hidden part of the iceberg.
I've already written the i2c slave part (and the acpi handling to get
the HID register by using the DSM should work), but I need now the
whole ACPI pnp drivers...
But without a real ACPI 5.0 mainboard, I think it will be quite
difficult to implement and debug this ACPI stuff.
Cheers,
Benjamin
On Thu, Jul 5, 2012 at 9:20 AM, Zhang Rui wrote:
> Hah, seems I forgot to reply to Benjamin.
>
> On 四, 2012-07-05 at 15:01 +0800, Zhang Rui wrote:
>> > Original Message
>> > Subject: Hid over I2C and ACPI interaction
>> > Date: Wed, 4 Jul 2012 15:46:35 +0200
>> > From: Benjamin Tissoires
>> > To: Jean Delvare , Ben Dooks ,
>> > Wolfram
>> > Sang , Len Brown ,
>> > , ,
>> >
>> > CC: Jiri Kosina , Stéphane Chatty , JJ
>> > Ding
>> >
>> >
>> > Hi Guys,
>> >
>> > I'm the co-author and the maintainer of the hid-multitouch driver. To
>> > support even more devices, I started the implementation of the HID
>> > over I2C protocol specification which is introduced by Win8. I'm quite
>> > comfortable with the hid and the I2C part, but I'm blocked with the
>> > interaction with the ACPI for the pnp part.
>> >
>> > I wanted to have your advice/help on this problem. I've add in the
>> > recipients list the maintainers of i2c and ACPI, sorry for the noise
>> > if you don't feel concerned about this.
>> >
>> > So, let's go deeper in the problem ;-)
>> > Microsoft's spec asks the OEM to fill the ACPI DSDT to provide the
>> > following scope in the ASL layout:
>> >
>> > > begin of ASL
>> > Scope (\_SB) {
>> > //
>> > // General Purpose I/O, ports 0...127
>> > //
>> >
>> > Device(HIDI2C_DEVICE1) {
>> > Name(_ADR,0)
>> > Name (_HID, "MSFT1234”)
>> > Name (_CID, "PNP0C50")
>> > Name (_UID, 3)
>> >
>> > Method(_CRS, 0x0, NotSerialized)
>> > {
>> > Name (RBUF, ResourceTemplate ()
>> > {
>> > // Address 0x07 on I2C-X (OEM selects this address)
>> > //IHV SPECIFIC I2C3 = I2C Controller; TGD0 = GPIO Controller;
>> > I2CSerialBus (0x07, ControllerInitiated,
>> > 10,AddressingMode7Bit, "\\_SB.I2C3")
>> > GpioInt(Level, ActiveLow, Exclusive, PullUp, 0, "\\_SB. TGD0",
>> > 0 , ResourceConsumer, , ) {40}
>> > })
>> > Return(RBUF)
>> > }
>> >
>> > Method(_DSM, 0x4, NotSerialized)
>> > {
>> > // BreakPoint
>> > Store ("Method _DSM begin", Debug)
>> >
>> > // DSM UUID
>> > switch(ToBuffer(Arg0))
>> > {
>> > // ACPI DSM UUID for HIDI2C
>> > case(ToUUID("3CDFF6F7-4267-4555-AD05-B30A3D8938DE"))
>> > {
>> > // DSM function which returns the HID Descriptor
>> > Address (skipped)
>> > }
>> >
>> > default
>> > {
>> > // No other GUIDs supported
>> > Return(Buffer(One) { 0x00 })
>> > }
>> > }
>> > }
>> > }
>> > < end of ASL
>> >
>> yep, this is an ACPI enumerated I2C controller.
>>
>> > Summary:
>> > - a HID over I2C device has to present the Compatibility ID "PNP0C50"
>> > - in the _CRS block, the address, the adapter and the gpioInt are
>> > defined (or referenced)
>> > - it presents a Device Specific Method (_DSM) which returns the HID
>> > Descriptor register address. This register is our entry point for
>> > retrieving the information about our hid device (so it's mandatory to
>> > obtain it).
>> >
>> > Where am I:
>> > - I've written a first layer on top of i2c that retrieves the hid
>> > register (currently the address 0x0001 is hardcoded), then get the
>> > report desccriptors and the input events, and forward all this stuff
>> > to the hid layer.
>> > - It's working with a custom emulated HID over i2c touchpad, while
>> > waiting for the one a manufacturer should send to me.
>> > - The detection and the addition to the adapter is done by adding the
>> > address in the lists and the name through the i2c "->detect" callback
>> > (which is not very good, because I don't have the interrupt line
>> > there).
>> > - I've written a first acpi implementation that rely on the
>> > DEVICE_ACPI_HANDLE macro to get the ACPI handle of the device (if
>> > available).
>> > - I'm not able to do some tests with the ACPI, as I don't know how to
>> > implement this DSDT on my computer (I'm missing the I2C part), and the
>> > manufacturer returned the mainboard with the right DSDT to the OEM.
>> >
>> > My questions:
>> > - will the current acpi implementation handle I2C devices?
>>
>> you still need to write your own device driver for the device.
>>
>> > - it seems to me that the .archdata field is left blank during the i2c
>> > device initialization in all paths I've seen. Is that true?
>> > - who puts the name int the struct i2c_board_info
Re: [PATCH 7/8 v3] i2c: i801: enable irq for i801 smbus transactions
Hi Daniel, On Thu, 5 Jul 2012 12:31:11 +0800, Daniel Kurtz wrote: > On Thu, Jul 5, 2012 at 4:16 AM, Jean Delvare wrote: > > You should be able to reproduce this bug by loading i2c-i801 with > > option disable_features=0x0002, assuming your SMBus IRQ is shared. > > > > This leads me to several thoughts (feel free to correct me if I'm > > wrong, I am getting very tired): > > > > 1* This must be the reason why a bit was added to the PCI status > >register starting with the ICH5, telling you if an interrupt has been > >delivered to you. Checking for it as you originally did was a good idea > >after all. > > Reducing scope to get accepted patches in sooner sounds like a good plan to > me. Agreed. > > 2* Is there any reason why you decided to clear the status bits in > >i801_isr(), rather than after wait_event()? I am no expert in > >interrupt handling, I admit, but letting the "caller" clear the status > >bits would ensure we don't clear status bits when nobody is actually > >waiting to catch them. > > BYTE_DONE is cleared to kick off the next byte, and it doesn't > generate a wait_event, thus it is cleared right in the irq. No problem with BYTE_DONE. > The logic for clearing the STATUS_FLAGS was simply that they all > indicate the end of a transaction, so there won't be any further > interrupts. Thus, it is safe to clear it in the irq, since the irq > will be followed by exactly one wait_event, which can read and process > saved status. It is safe if and only if someone is actually listening to the event. This was not the case for me yesterday. Even if we don't mix interrupts and polling, i801_isr() might still get called when we aren't listening. Not only because the IRQ may be shared, but also for events we don't yet handle, such as an SMBus Alert. Not sure about slave mode. > > 3* Applying this patch (7/8) without the one adding interrupt support > >to i801_block_transaction_byte_by_byte (8/8) is not OK: mixing > >interrupts and polling isn't safe. So unless we implement 1* or 2*, > >both patches would have to be merged before being pushed upstream. > > > > 4* Even then, we have to keep in mind that i801_isr() may be called > >before the transaction is finished (if IRQ is shared.) My testing > >has shown that error flags may be raised before the BUSY flag is > >cleared, so we should use in i801_isr() the same strict conditions > >we are now using in the polling code. In other words, if we get an > >interrupt but the BUSY flag is still set, then it's not our > >interrupt and we should ignore it. This applies even if 2* or 3* > >above are implemented, but no longer if 1* is implemented. > > > > 5* Your claim that no locking is needed might have to be revisited when > >interrupts are shared. > > > > Implementing 1* has the drawback of limiting interrupt support to ICH5 > > and later chips, but I suspect it is the easiest and safest way, so I > > have no objection if you want to do that. > > Let's do this first, and then refactor later to add support for > pre-ICH5 parts, if needed. OK, fine with me. The only downside is that it excludes my heavily-shared IRQ test machine, so testing that the shared IRQ case is properly covered will be a little harder. > It sounds like supporting the pre-ICH5 parts w/ shared IRQ is not very > pretty, since we are no longer guaranteed that we get a single > transaction terminating interrupt. Indeed. In that case, using interrupts will be much like using polling, except that status check happens whenever we receive an interrupt, rather than at fixed time interval. > Do you still maintain a public git repository? I never did. > Have you updated it with the accepted version of the previous cleanup patches? > I see this one, but it doesn't look updated: > http://git.kernel.org/?p=linux/kernel/git/jdelvare/staging.git;a=summary This tree is only for sending patches to Linus. It doesn't reflect the current status of my working tree. I am maintaining quilt series for that, which you can find at: http://khali.linux-fr.org/devel/linux-3/ > I'd like to fix up the interrupt patches per your feedback, but I'm > not quite sure what the current status is of all the cleanup patches. > > In other words, if you push up the complete set of cleanup patches, I > can then rebase the new consolidated irq patch onto it, and send them > here for review. I updated the i2c series this morning, so it's up-to-date. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Hid over I2C and ACPI interaction
Hah, seems I forgot to reply to Benjamin.
On 四, 2012-07-05 at 15:01 +0800, Zhang Rui wrote:
> > Original Message
> > Subject: Hid over I2C and ACPI interaction
> > Date: Wed, 4 Jul 2012 15:46:35 +0200
> > From: Benjamin Tissoires
> > To: Jean Delvare , Ben Dooks ,
> > Wolfram
> > Sang , Len Brown ,
> > , ,
> >
> > CC: Jiri Kosina , Stéphane Chatty , JJ
> > Ding
> >
> >
> > Hi Guys,
> >
> > I'm the co-author and the maintainer of the hid-multitouch driver. To
> > support even more devices, I started the implementation of the HID
> > over I2C protocol specification which is introduced by Win8. I'm quite
> > comfortable with the hid and the I2C part, but I'm blocked with the
> > interaction with the ACPI for the pnp part.
> >
> > I wanted to have your advice/help on this problem. I've add in the
> > recipients list the maintainers of i2c and ACPI, sorry for the noise
> > if you don't feel concerned about this.
> >
> > So, let's go deeper in the problem ;-)
> > Microsoft's spec asks the OEM to fill the ACPI DSDT to provide the
> > following scope in the ASL layout:
> >
> > > begin of ASL
> > Scope (\_SB) {
> > //
> > // General Purpose I/O, ports 0...127
> > //
> >
> > Device(HIDI2C_DEVICE1) {
> > Name(_ADR,0)
> > Name (_HID, "MSFT1234”)
> > Name (_CID, "PNP0C50")
> > Name (_UID, 3)
> >
> > Method(_CRS, 0x0, NotSerialized)
> > {
> > Name (RBUF, ResourceTemplate ()
> > {
> > // Address 0x07 on I2C-X (OEM selects this address)
> > //IHV SPECIFIC I2C3 = I2C Controller; TGD0 = GPIO Controller;
> > I2CSerialBus (0x07, ControllerInitiated,
> > 10,AddressingMode7Bit, "\\_SB.I2C3")
> > GpioInt(Level, ActiveLow, Exclusive, PullUp, 0, "\\_SB. TGD0",
> > 0 , ResourceConsumer, , ) {40}
> > })
> > Return(RBUF)
> > }
> >
> > Method(_DSM, 0x4, NotSerialized)
> > {
> > // BreakPoint
> > Store ("Method _DSM begin", Debug)
> >
> > // DSM UUID
> > switch(ToBuffer(Arg0))
> > {
> > // ACPI DSM UUID for HIDI2C
> > case(ToUUID("3CDFF6F7-4267-4555-AD05-B30A3D8938DE"))
> > {
> > // DSM function which returns the HID Descriptor
> > Address (skipped)
> > }
> >
> > default
> > {
> > // No other GUIDs supported
> > Return(Buffer(One) { 0x00 })
> > }
> > }
> > }
> > }
> > < end of ASL
> >
> yep, this is an ACPI enumerated I2C controller.
>
> > Summary:
> > - a HID over I2C device has to present the Compatibility ID "PNP0C50"
> > - in the _CRS block, the address, the adapter and the gpioInt are
> > defined (or referenced)
> > - it presents a Device Specific Method (_DSM) which returns the HID
> > Descriptor register address. This register is our entry point for
> > retrieving the information about our hid device (so it's mandatory to
> > obtain it).
> >
> > Where am I:
> > - I've written a first layer on top of i2c that retrieves the hid
> > register (currently the address 0x0001 is hardcoded), then get the
> > report desccriptors and the input events, and forward all this stuff
> > to the hid layer.
> > - It's working with a custom emulated HID over i2c touchpad, while
> > waiting for the one a manufacturer should send to me.
> > - The detection and the addition to the adapter is done by adding the
> > address in the lists and the name through the i2c "->detect" callback
> > (which is not very good, because I don't have the interrupt line
> > there).
> > - I've written a first acpi implementation that rely on the
> > DEVICE_ACPI_HANDLE macro to get the ACPI handle of the device (if
> > available).
> > - I'm not able to do some tests with the ACPI, as I don't know how to
> > implement this DSDT on my computer (I'm missing the I2C part), and the
> > manufacturer returned the mainboard with the right DSDT to the OEM.
> >
> > My questions:
> > - will the current acpi implementation handle I2C devices?
>
> you still need to write your own device driver for the device.
>
> > - it seems to me that the .archdata field is left blank during the i2c
> > device initialization in all paths I've seen. Is that true?
> > - who puts the name int the struct i2c_board_info? (for hot-plugged
> > i2c devices).
> >
> > - finally, what is the best way of handling ACPI for those I2C devices:
> >1) everything is fine, I should have the ACPI handle in .archdata.
> >2) someone has to implement the handling of I2C in the pnpACPI layer
> > (by adding I2CSerialBus handling and creating there the i2c slave).
> >3) I should create an acpi driver which handles "PNP0C50" and which
> > creates the i2c slaves.
> >
> exactly.
>
> As this I2C controller uses the GPIO interrupt, we need an ACPI GPIO
> controller driver for interrupts
Re: Fwd: Hid over I2C and ACPI interaction
> Original Message
> Subject: Hid over I2C and ACPI interaction
> Date: Wed, 4 Jul 2012 15:46:35 +0200
> From: Benjamin Tissoires
> To: Jean Delvare , Ben Dooks ,
> Wolfram
> Sang , Len Brown ,
> , ,
>
> CC: Jiri Kosina , Stéphane Chatty , JJ Ding
>
>
> Hi Guys,
>
> I'm the co-author and the maintainer of the hid-multitouch driver. To
> support even more devices, I started the implementation of the HID
> over I2C protocol specification which is introduced by Win8. I'm quite
> comfortable with the hid and the I2C part, but I'm blocked with the
> interaction with the ACPI for the pnp part.
>
> I wanted to have your advice/help on this problem. I've add in the
> recipients list the maintainers of i2c and ACPI, sorry for the noise
> if you don't feel concerned about this.
>
> So, let's go deeper in the problem ;-)
> Microsoft's spec asks the OEM to fill the ACPI DSDT to provide the
> following scope in the ASL layout:
>
> > begin of ASL
> Scope (\_SB) {
> //
> // General Purpose I/O, ports 0...127
> //
>
> Device(HIDI2C_DEVICE1) {
> Name(_ADR,0)
> Name (_HID, "MSFT1234”)
> Name (_CID, "PNP0C50")
> Name (_UID, 3)
>
> Method(_CRS, 0x0, NotSerialized)
> {
> Name (RBUF, ResourceTemplate ()
> {
> // Address 0x07 on I2C-X (OEM selects this address)
> //IHV SPECIFIC I2C3 = I2C Controller; TGD0 = GPIO Controller;
> I2CSerialBus (0x07, ControllerInitiated,
> 10,AddressingMode7Bit, "\\_SB.I2C3")
> GpioInt(Level, ActiveLow, Exclusive, PullUp, 0, "\\_SB. TGD0",
> 0 , ResourceConsumer, , ) {40}
> })
> Return(RBUF)
> }
>
> Method(_DSM, 0x4, NotSerialized)
> {
> // BreakPoint
> Store ("Method _DSM begin", Debug)
>
> // DSM UUID
> switch(ToBuffer(Arg0))
> {
> // ACPI DSM UUID for HIDI2C
> case(ToUUID("3CDFF6F7-4267-4555-AD05-B30A3D8938DE"))
> {
> // DSM function which returns the HID Descriptor
> Address (skipped)
> }
>
> default
> {
> // No other GUIDs supported
> Return(Buffer(One) { 0x00 })
> }
> }
> }
> }
> < end of ASL
>
yep, this is an ACPI enumerated I2C controller.
> Summary:
> - a HID over I2C device has to present the Compatibility ID "PNP0C50"
> - in the _CRS block, the address, the adapter and the gpioInt are
> defined (or referenced)
> - it presents a Device Specific Method (_DSM) which returns the HID
> Descriptor register address. This register is our entry point for
> retrieving the information about our hid device (so it's mandatory to
> obtain it).
>
> Where am I:
> - I've written a first layer on top of i2c that retrieves the hid
> register (currently the address 0x0001 is hardcoded), then get the
> report desccriptors and the input events, and forward all this stuff
> to the hid layer.
> - It's working with a custom emulated HID over i2c touchpad, while
> waiting for the one a manufacturer should send to me.
> - The detection and the addition to the adapter is done by adding the
> address in the lists and the name through the i2c "->detect" callback
> (which is not very good, because I don't have the interrupt line
> there).
> - I've written a first acpi implementation that rely on the
> DEVICE_ACPI_HANDLE macro to get the ACPI handle of the device (if
> available).
> - I'm not able to do some tests with the ACPI, as I don't know how to
> implement this DSDT on my computer (I'm missing the I2C part), and the
> manufacturer returned the mainboard with the right DSDT to the OEM.
>
> My questions:
> - will the current acpi implementation handle I2C devices?
you still need to write your own device driver for the device.
> - it seems to me that the .archdata field is left blank during the i2c
> device initialization in all paths I've seen. Is that true?
> - who puts the name int the struct i2c_board_info? (for hot-plugged
> i2c devices).
>
> - finally, what is the best way of handling ACPI for those I2C devices:
>1) everything is fine, I should have the ACPI handle in .archdata.
>2) someone has to implement the handling of I2C in the pnpACPI layer
> (by adding I2CSerialBus handling and creating there the i2c slave).
>3) I should create an acpi driver which handles "PNP0C50" and which
> creates the i2c slaves.
>
exactly.
As this I2C controller uses the GPIO interrupt, we need an ACPI GPIO
controller driver for interrupts first.
I already have such a patch in hand, but have not release it for some
reason.
Second, you need to write your own PNP I2C controller driver, to
enumerate the I2C controller via ACPI, AND enumerate the I2C slave
devices under this controller to I2C bus. I also have a similar driver
for SPI controller and SD/MMC controller.
Third, you need a I2C s
