Re: [linux-nfc] [PATCH] NFC: trf7970a: Move trf7970a_init inside #ifdef CONFIG_PM_RUNTIME
On Mon, Jun 16, 2014 at 08:58:55AM -0700, Mark A. Greer wrote: > On Mon, Jun 16, 2014 at 03:06:13PM +0200, Geert Uytterhoeven wrote: > > If CONFIG_PM_RUNTIME=n: > > > > drivers/nfc/trf7970a.c:755: warning: ‘trf7970a_init’ defined but not used > > > > Signed-off-by: Geert Uytterhoeven > > Acked-by: Mark A. Greer Actually, I'd like to change my mind on this. I've modified the code locally and I will have to move trf7970a_init() back to where it originally was again, if this patch is taken. If you can tolerate the warning for another week or so, I'll have a new set of patches that will fix it. Not a big deal if you still want to take it. Mark -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NFC: trf7970a: Move trf7970a_init inside #ifdef CONFIG_PM_RUNTIME
On Mon, Jun 16, 2014 at 03:06:13PM +0200, Geert Uytterhoeven wrote: > If CONFIG_PM_RUNTIME=n: > > drivers/nfc/trf7970a.c:755: warning: ‘trf7970a_init’ defined but not used > > Signed-off-by: Geert Uytterhoeven Acked-by: Mark A. Greer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bq24190: What's the correct API to turn boost mode (OTG) on for the battery charger ?
[Removing Anton from CC] On Wed, May 21, 2014 at 11:25:43AM -0700, Mark A. Greer wrote: > On Fri, May 16, 2014 at 12:35:34AM +0200, Laurent Pinchart wrote: > > Hi Mark, > > > > Thank you for the quick reply. > > Hi Laurent. Sorry for the delay. > > > On Thursday 15 May 2014 15:08:44 Mark A. Greer wrote: > > > On Thu, May 15, 2014 at 10:29:26PM +0200, Laurent Pinchart wrote: > > > > Hello, > > > > > > [Adding Anton Vorontsov to CC list.] > > > > > > Hi Laurent. > > > > > > > I'm trying to enable battery charging on an OMAP4 board based on a > > > > twl6030 > > > > PMIC with external bq24190 battery charger and bq27510 fuel gauge. > > > > > > > > The system has an OTG USB port that can be used to charge the battery, > > > > and > > > > that can also be used in host mode. In that case the bq24190 needs to be > > > > switched to boost mode to provide the +5V power supply from the battery. > > > > > > > > The bq24190 has a charge configuration register field that supports > > > > charge > > > > disabled, charge enabled and OTG (boost mode). The field is set by the > > > > bq24190 driver in response to setting the charge type : > > > > POWER_SUPPLY_CHARGE_TYPE_NONE will disable charing, and > > > > POWER_SUPPLY_CHARGE_TYPE_TRICKLE and > > > > POWER_SUPPLY_CHARGE_TYPE_FAST will enable it. However, OTG boost mode is > > > > not supported. > > > > > > > > > > > > The driver exposes most register fields as sysfs attributes (which > > > > doesn't > > > > sound very safe to me, but that's another story). I can thus enable OTG > > > > boost mode directly from userspace through the driver-specific API, but > > > > that just bypasses the power supply API. I'm thus not very fond of that > > > > solution. > > > > > > No, its not a good solution. As indicated in the commit log, the sysfs > > > entries are there because there are just so many fields that don't map > > > well to the existing interface. > > > > > > Maybe we should add support for a DT entry to enable exporting those > > > fields(disabled by default)? > > > > > > > Possibly due to my really basic (not to say nonexistent) knowledge of > > > > the > > > > power supply subsystem I haven't found an API to expose this feature. I > > > > was wondering if someone had given a though regarding how to implement > > > > this properly. > > > > > > What if we just added something like POWER_SUPPLY_CHARGE_TYPE_BOOST? > > > > That was actually my first thought, and I assumed it would be rejected as > > boost mode is not a charge type but a discharge type :-) > > Er, right. :( > > > This being said, I > > don't have enough experience with battery chargers to decide whether this > > is a > > good solution. If you believe it is, I'll trust you on that. > > No, you're right, that isn't a good solution. > > I don't see a really good fit anywhere. The easiest thing may be to add > a new POWER_SUPPLY_PROP_xxx power_supply_property member which can be set > to flip it into boost mode but I'm not sure if that's really the right > thing to do. > > I hope Anton will comment on this. After looking at MAINTAINERS and its git log, it looks like Dmitry has taken over. Dmitry, do you have anything insight? Mark -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bq24190: What's the correct API to turn boost mode (OTG) on for the battery charger ?
On Wed, May 21, 2014 at 11:25:43AM -0700, Mark A. Greer wrote: > On Fri, May 16, 2014 at 12:35:34AM +0200, Laurent Pinchart wrote: > > On a side note, is there any reference userspace implementation of a > > battery > > manager ? The vendor BSP I've received with the board hardcodes calls to > > the > > bq24190 in the MUSB driver to switch between OTG and trickle charge modes > > based on USB cable connection/disconnection events. That's pretty ugly, and > > I > > assume this should be handled in userspace - or is there a standard kernel > > infrastructure for that ? > > I don't have a good feel for what's out there but the charger-manager may > be a good place to start: > > Documentation/power/charger-manager.txt > drivers/power/charger-manager.c And, http://elinux.org/images/c/c6/Elce11_ham.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bq24190: What's the correct API to turn boost mode (OTG) on for the battery charger ?
On Fri, May 16, 2014 at 12:35:34AM +0200, Laurent Pinchart wrote: > Hi Mark, > > Thank you for the quick reply. Hi Laurent. Sorry for the delay. > On Thursday 15 May 2014 15:08:44 Mark A. Greer wrote: > > On Thu, May 15, 2014 at 10:29:26PM +0200, Laurent Pinchart wrote: > > > Hello, > > > > [Adding Anton Vorontsov to CC list.] > > > > Hi Laurent. > > > > > I'm trying to enable battery charging on an OMAP4 board based on a twl6030 > > > PMIC with external bq24190 battery charger and bq27510 fuel gauge. > > > > > > The system has an OTG USB port that can be used to charge the battery, and > > > that can also be used in host mode. In that case the bq24190 needs to be > > > switched to boost mode to provide the +5V power supply from the battery. > > > > > > The bq24190 has a charge configuration register field that supports charge > > > disabled, charge enabled and OTG (boost mode). The field is set by the > > > bq24190 driver in response to setting the charge type : > > > POWER_SUPPLY_CHARGE_TYPE_NONE will disable charing, and > > > POWER_SUPPLY_CHARGE_TYPE_TRICKLE and > > > POWER_SUPPLY_CHARGE_TYPE_FAST will enable it. However, OTG boost mode is > > > not supported. > > > > > > > > > The driver exposes most register fields as sysfs attributes (which doesn't > > > sound very safe to me, but that's another story). I can thus enable OTG > > > boost mode directly from userspace through the driver-specific API, but > > > that just bypasses the power supply API. I'm thus not very fond of that > > > solution. > > > > No, its not a good solution. As indicated in the commit log, the sysfs > > entries are there because there are just so many fields that don't map > > well to the existing interface. > > > > Maybe we should add support for a DT entry to enable exporting those > > fields(disabled by default)? > > > > > Possibly due to my really basic (not to say nonexistent) knowledge of the > > > power supply subsystem I haven't found an API to expose this feature. I > > > was wondering if someone had given a though regarding how to implement > > > this properly. > > > > What if we just added something like POWER_SUPPLY_CHARGE_TYPE_BOOST? > > That was actually my first thought, and I assumed it would be rejected as > boost mode is not a charge type but a discharge type :-) Er, right. :( > This being said, I > don't have enough experience with battery chargers to decide whether this is > a > good solution. If you believe it is, I'll trust you on that. No, you're right, that isn't a good solution. I don't see a really good fit anywhere. The easiest thing may be to add a new POWER_SUPPLY_PROP_xxx power_supply_property member which can be set to flip it into boost mode but I'm not sure if that's really the right thing to do. I hope Anton will comment on this. > On a side note, is there any reference userspace implementation of a battery > manager ? The vendor BSP I've received with the board hardcodes calls to the > bq24190 in the MUSB driver to switch between OTG and trickle charge modes > based on USB cable connection/disconnection events. That's pretty ugly, and I > assume this should be handled in userspace - or is there a standard kernel > infrastructure for that ? I don't have a good feel for what's out there but the charger-manager may be a good place to start: Documentation/power/charger-manager.txt drivers/power/charger-manager.c HTH, Mark -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bq24190: What's the correct API to turn boost mode (OTG) on for the battery charger ?
On Thu, May 15, 2014 at 10:29:26PM +0200, Laurent Pinchart wrote: > Hello, [Adding Anton Vorontsov to CC list.] Hi Laurent. > I'm trying to enable battery charging on an OMAP4 board based on a twl6030 > PMIC with external bq24190 battery charger and bq27510 fuel gauge. > > The system has an OTG USB port that can be used to charge the battery, and > that can also be used in host mode. In that case the bq24190 needs to be > switched to boost mode to provide the +5V power supply from the battery. > > The bq24190 has a charge configuration register field that supports charge > disabled, charge enabled and OTG (boost mode). The field is set by the > bq24190 > driver in response to setting the charge type : POWER_SUPPLY_CHARGE_TYPE_NONE > will disable charing, and POWER_SUPPLY_CHARGE_TYPE_TRICKLE and > POWER_SUPPLY_CHARGE_TYPE_FAST will enable it. However, OTG boost mode is not > supported. > > The driver exposes most register fields as sysfs attributes (which doesn't > sound very safe to me, but that's another story). I can thus enable OTG boost > mode directly from userspace through the driver-specific API, but that just > bypasses the power supply API. I'm thus not very fond of that solution. No, its not a good solution. As indicated in the commit log, the sysfs entries are there because there are just so many fields that don't map well to the existing interface. Maybe we should add support for a DT entry to enable exporting those fields(disabled by default)? > Possibly due to my really basic (not to say nonexistent) knowledge of the > power supply subsystem I haven't found an API to expose this feature. I was > wondering if someone had given a though regarding how to implement this > properly. What if we just added something like POWER_SUPPLY_CHARGE_TYPE_BOOST? Mark -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] bq24190_charger: Add support for TI BQ24190 Battery Charger
Add driver support for the Texas Instruments BQ24190 battery charger. Some of the information provided by the device is about the charger and other information is about the battery so create two power_supply objects (one for each) and provide the appropriate information for each one. The device has many fields that go beyond what is reasonable to report or modify using the existing 'POWER_SUPPLY_PROP_*' properties so the driver exports the register fields via sysfs. They are prefixed by 'f_' (for 'field') to make it easier to distinguish between a register field and a "normal" sysfs file exported by the power_supply infrastructure. Signed-off-by: Mark A. Greer --- - Tested on an ARM 3703-based platform which hasn't been submitted to the community yet. - Patch tested on k.o 89b53e5 (Merge branch 'for-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata) plus patches for platform mentioned above. - Information on the device is available here: http://www.ti.com/product/bq24190?DCMP=hpa-pmp-battery-bq2419x-en&HQS=bq24190-pr - Change from v1: - 'first_time' is now per-device - The OF irq code changed to use irq_of_parse_and_map() - Unnecessary goto's removed - Now builds and works when CONFIG_SYSFS is not defined - When removing driver, the registers are reset instead of just turning default mode back on drivers/power/Kconfig |6 + drivers/power/Makefile|1 + drivers/power/bq24190_charger.c | 1548 + include/linux/power/bq24190_charger.h | 16 + 4 files changed, 1571 insertions(+) create mode 100644 drivers/power/bq24190_charger.c create mode 100644 include/linux/power/bq24190_charger.h diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 7b8979c..c31ec0a 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -334,6 +334,12 @@ config CHARGER_BQ2415X You'll need this driver to charge batteries on e.g. Nokia RX-51/N900. +config CHARGER_BQ24190 + tristate "TI BQ24190 battery charger driver" + depends on I2C && GPIOLIB + help + Say Y to enable support for the TI BQ24190 battery charger. + config CHARGER_SMB347 tristate "Summit Microelectronics SMB347 Battery Charger" depends on I2C diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 653bf6c..4ae4533 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -50,6 +50,7 @@ obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o +obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o obj-$(CONFIG_POWER_AVS)+= avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o diff --git a/drivers/power/bq24190_charger.c b/drivers/power/bq24190_charger.c new file mode 100644 index 000..5619786 --- /dev/null +++ b/drivers/power/bq24190_charger.c @@ -0,0 +1,1548 @@ +/* + * Driver for the TI bq24190 battery charger. + * + * Author: Mark A. Greer + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + + +#defineBQ24190_MANUFACTURER"Texas Instruments" + +#define BQ24190_REG_ISC0x00 /* Input Source Control */ +#define BQ24190_REG_ISC_EN_HIZ_MASKBIT(7) +#define BQ24190_REG_ISC_EN_HIZ_SHIFT 7 +#define BQ24190_REG_ISC_VINDPM_MASK(BIT(6) | BIT(5) | BIT(4) | \ +BIT(3)) +#define BQ24190_REG_ISC_VINDPM_SHIFT 3 +#define BQ24190_REG_ISC_IINLIM_MASK(BIT(2) | BIT(1) | BIT(0)) +#define BQ24190_REG_ISC_IINLIM_SHIFT 0 + +#define BQ24190_REG_POC0x01 /* Power-On Configuration */ +#define BQ24190_REG_POC_RESET_MASK BIT(7) +#define BQ24190_REG_POC_RESET_SHIFT7 +#define BQ24190_REG_POC_WDT_RESET_MASK BIT(6) +#define BQ24190_REG_POC_WDT_RESET_SHIFT6 +#define BQ24190_REG_POC_CHG_CONFIG_MASK(BIT(5) | BIT(4)) +#define BQ24190_REG_POC_CHG_CONFIG_SHIFT 4 +#define BQ24190_REG_POC_SYS_MIN_MASK (BIT(3) | BIT(2) | BIT(1)) +#define BQ24190_REG_POC_SYS_MIN_SHIFT 1 +#define BQ24190_REG_POC_BOOST_LIM_MASK BIT(0) +#define BQ24190_REG_POC_BOOST_LIM_SHIFT0 + +#define BQ24190_REG_CCC0x02 /* Charge Current Control */ +#define BQ24190_REG_CCC_ICHG_MASK (BIT(7) | BIT(6) | BIT(
Re: [PATCH] bq24190_charger: Add support for TI BQ24190 Battery Charger
On Fri, Aug 09, 2013 at 12:21:11PM -0700, Anton Vorontsov wrote:
> On Wed, Aug 07, 2013 at 02:56:48PM -0700, Mark A. Greer wrote:
> ...
> > +static irqreturn_t bq24190_irq_handler_thread(int irq, void *data)
> > +{
> > + struct bq24190_dev_info *bdi = data;
> > + bool alert_userspace = false;
> > + u8 ss_reg, f_reg;
> > + int ret;
> > + static bool first_time = true;
> ...
> > + /*
> > +* Sometimes bq24190 gives a steady trickle of interrupts even
> > +* though the watchdog timer is turned off and neither the STATUS
> > +* nor FAULT registers have changed. Weed out these sprurious
> > +* interrupts so userspace isn't alerted for no reason.
> > +* In addition, the chip always generates an interrupt after
> > +* register reset so we should ignore that one (the very first
> > +* interrupt received).
> > +*/
> > + if (alert_userspace && !first_time) {
>
> Hm, global static... I would guess that per-device flag would be more
> appropriate, just in case if there are multiple chargers?
Oops.
> ...
> > + do {
> > + ret = bq24190_read_mask(bdi, BQ24190_REG_POC,
> > + BQ24190_REG_POC_RESET_MASK,
> > + BQ24190_REG_POC_RESET_SHIFT,
> > + &v);
> > + if ((ret <= 0) || !v)
> > + break;
> > +
> > + udelay(10);
> > + } while (--limit);
> > +
> > + if (!ret && limit)
> > + ret = bq24190_set_mode_host(bdi);
> > +out:
> > + pm_runtime_put_sync(bdi->dev);
> > + return ret;
> > +}
> > +
> > +#define irq_to_gpio(irq) ((irq) - gpio_to_irq(0))
>
> Ugh... this does not seem right. On a particular platform it might work,
> but not in general...
Umm, yeah. Plain laziness on my part.
> p.s. I am also not a big fan of unnecessary 'out:' goto labels... most of
> them might be changed to just 'return ...;'
OK.
Mark
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] bq24190_charger: Add support for TI BQ24190 Battery Charger
Add driver support for the Texas Instruments BQ24190 battery charger. Some of the information provided by the device is about the charger and other information is about the battery so create two power_supply objects (one for each) and provide the appropriate information for each one. The device has many fields that go beyond what is reasonable to report or modify using the existing 'POWER_SUPPLY_PROP_*' properties so the driver exports the register fields via sysfs. They are prefixed by 'f_' (for 'field') to make it easier to distinguish between a register field and a "normal" sysfs file exported by the power_supply infrastructure. Signed-off-by: Mark A. Greer --- - Tested on an ARM 3703-based platform which hasn't been submitted to the community yet. - Patch based on git://git.infradead.org/battery-2.6.git but was tested on stock 3.10 plus patches for platform mentioned above. - Information on the device is available here: http://www.ti.com/product/bq24190?DCMP=hpa-pmp-battery-bq2419x-en&HQS=bq24190-pr drivers/power/Kconfig |6 + drivers/power/Makefile|1 + drivers/power/bq24190_charger.c | 1538 + include/linux/power/bq24190_charger.h | 16 + 4 files changed, 1561 insertions(+) create mode 100644 drivers/power/bq24190_charger.c create mode 100644 include/linux/power/bq24190_charger.h diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 7b8979c..c31ec0a 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -334,6 +334,12 @@ config CHARGER_BQ2415X You'll need this driver to charge batteries on e.g. Nokia RX-51/N900. +config CHARGER_BQ24190 + tristate "TI BQ24190 battery charger driver" + depends on I2C && GPIOLIB + help + Say Y to enable support for the TI BQ24190 battery charger. + config CHARGER_SMB347 tristate "Summit Microelectronics SMB347 Battery Charger" depends on I2C diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 653bf6c..4ae4533 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -50,6 +50,7 @@ obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o +obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o obj-$(CONFIG_POWER_AVS)+= avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o diff --git a/drivers/power/bq24190_charger.c b/drivers/power/bq24190_charger.c new file mode 100644 index 000..f077fe6 --- /dev/null +++ b/drivers/power/bq24190_charger.c @@ -0,0 +1,1538 @@ +/* + * Driver for the TI bq24190 battery charger. + * + * Author: Mark A. Greer + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + + +#defineBQ24190_MANUFACTURER"Texas Instruments" + +#define BQ24190_REG_ISC0x00 /* Input Source Control */ +#define BQ24190_REG_ISC_EN_HIZ_MASKBIT(7) +#define BQ24190_REG_ISC_EN_HIZ_SHIFT 7 +#define BQ24190_REG_ISC_VINDPM_MASK(BIT(6) | BIT(5) | BIT(4) | \ +BIT(3)) +#define BQ24190_REG_ISC_VINDPM_SHIFT 3 +#define BQ24190_REG_ISC_IINLIM_MASK(BIT(2) | BIT(1) | BIT(0)) +#define BQ24190_REG_ISC_IINLIM_SHIFT 0 + +#define BQ24190_REG_POC0x01 /* Power-On Configuration */ +#define BQ24190_REG_POC_RESET_MASK BIT(7) +#define BQ24190_REG_POC_RESET_SHIFT7 +#define BQ24190_REG_POC_WDT_RESET_MASK BIT(6) +#define BQ24190_REG_POC_WDT_RESET_SHIFT6 +#define BQ24190_REG_POC_CHG_CONFIG_MASK(BIT(5) | BIT(4)) +#define BQ24190_REG_POC_CHG_CONFIG_SHIFT 4 +#define BQ24190_REG_POC_SYS_MIN_MASK (BIT(3) | BIT(2) | BIT(1)) +#define BQ24190_REG_POC_SYS_MIN_SHIFT 1 +#define BQ24190_REG_POC_BOOST_LIM_MASK BIT(0) +#define BQ24190_REG_POC_BOOST_LIM_SHIFT0 + +#define BQ24190_REG_CCC0x02 /* Charge Current Control */ +#define BQ24190_REG_CCC_ICHG_MASK (BIT(7) | BIT(6) | BIT(5) | \ +BIT(4) | BIT(3) | BIT(2)) +#define BQ24190_REG_CCC_ICHG_SHIFT 2 +#define BQ24190_REG_CCC_FORCE_20PCT_MASK BIT(0) +#define BQ24190_REG_CCC_FORCE_20PCT_SHIFT 0 + +#define BQ24190_REG_PCTCC 0x03 /* Pre-charge/Termination Current Cntl */ +#define BQ24190_REG_PCTCC_IPRECHG_MASK (BI
Re: crypto: omap-sham, omap-aes and dma_request_slave_channel_compat()
[CC'ing more people & lists.] On Tue, Feb 26, 2013 at 11:36:46AM -0700, Tim Gardner wrote: > Whats up with commits 0e87e73f4abe1ada69cf780fe2550c6361a1b53b and > b4b87a934c30fb91cbdd18ae028acdc361e1cf0f. As far as I can tell, > dma_request_slave_channel_compat() does not exist in 3.9 as of > 52caa59ed335616c5254adff7911465a57ed9f14, nor does it exist in > linux-next as of Feb 26. Am I just being dense ? Yeah, order got a little messed up. The problem is known and the sub-thread talking about it starts about here: http://www.spinics.net/lists/arm-kernel/msg225241.html with the conclusion (AFAICT) that Vinod is to push it: http://www.spinics.net/lists/arm-kernel/msg226062.html > Reverting those 2 commits at least allows the compile complete. When the dependencies are sorted out, will you revert the revert or do I need to do something? Mark -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Don't mark shared helper functions as inline
On Mon, Nov 26, 2012 at 11:57:42AM -0800, Mike Turquette wrote: > Quoting Russ Dill (2012-11-26 11:20:09) > > The helper functions that access the opaque struct clk should > > not be marked inline since they are contained in clk.c, but expected > > to be used by other compilation units. This causes compile errors > > under gcc-4.7 > > > > In file included from arch/arm/mach-omap2/clockdomain.c:25:0: > > arch/arm/mach-omap2/clockdomain.c: In function ‘clkdm_clk_disable’: > > include/linux/clk-provider.h:338:12: error: inlining failed in call to > > always_inline ‘__clk_get_enable_count’: function body not available > > arch/arm/mach-omap2/clockdomain.c:1001:28: error: called from here > > make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1 > > make: *** [arch/arm/mach-omap2] Error 2 > > > Hi Mike. > Regardless, I'm still considering this patch. I've heard many times > that we should trust the compiler to optimize for us and some folks look > down on inlining in general. If anyone has an opinion on removing > inlines from the common clk core then please do speak up. You should take a look at "Chapter 15: The inline disease" in Documentation/CodingStyle. Mark -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/15] arm-soc: changes for v3.6
On Tue, Jul 24, 2012 at 02:51:35PM -0600, Paul Walmsley wrote: > Hi > > On Tue, 24 Jul 2012, Arnd Bergmann wrote: > > > On Tuesday 24 July 2012, Linus Torvalds wrote: > > > > > In your "for-linus" branch, "&mpu_3xxx_clkdm" remains in the > > > clockdomains_common[] array. In my merge, it is gone. But I think I > > > did the merge correctly, and you did it wrong. HOWEVER, I don't know > > > the code, maybe there is some subtle reason why you did it like you > > > did. > > > > Yes, I think you are right now that I look at it again. Paul Walmsley > > can have another look at the merge and send an update if we are both > > missing something now. > > Linus' merge is correct. FWIW, it looks right to me too. Thanks, Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Serial: MPSC - Set baudrate when BRG divider is set.
From: Mark A. Greer <[EMAIL PROTECTED]>
The clock to generate the desired baudrate with the MPSC is first divided
by the Baud Rate Generator (BRG) and then by the MPSC itself. So, when
the BRG divider is changed, the MPSC divider must also be changed to
generate the correct baudrate. During MPSC initialization, the BRG
divider is changed but the MPSC divider isn't changed until much later.
This results in some printk's coming out garbled. To fix that, set the
MPSC divider at the same time that the BRG divider is changed.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]
---
drivers/serial/mpsc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c
index 4d643c9..cb3a919 100644
--- a/drivers/serial/mpsc.c
+++ b/drivers/serial/mpsc.c
@@ -612,6 +612,7 @@ static void mpsc_hw_init(struct mpsc_port_info *pi)
/* No preamble, 16x divider, low-latency, */
writel(0x04400400, pi->mpsc_base + MPSC_MMCRH);
+ mpsc_set_baudrate(pi, pi->default_baud);
if (pi->mirror_regs) {
pi->MPSC_CHR_1_m = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] serial: MPSC: Fix coding style and whitespace issues
Fix up mpsc.c to be aligned with Documentation/CodingStyle.
Also fix up some whitespace issues.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
drivers/serial/mpsc.c | 684
1 file changed, 283 insertions(+), 401 deletions(-)
diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c
index d948e83..4d643c9 100644
--- a/drivers/serial/mpsc.c
+++ b/drivers/serial/mpsc.c
@@ -93,9 +93,8 @@
#defineMPSC_TXBE_SIZE dma_get_cache_alignment()
#defineMPSC_TXB_SIZE (MPSC_TXR_ENTRIES * MPSC_TXBE_SIZE)
-#defineMPSC_DMA_ALLOC_SIZE (MPSC_RXR_SIZE + MPSC_RXB_SIZE +
\
- MPSC_TXR_SIZE + MPSC_TXB_SIZE + \
- dma_get_cache_alignment() /* for alignment */)
+#defineMPSC_DMA_ALLOC_SIZE (MPSC_RXR_SIZE + MPSC_RXB_SIZE +
MPSC_TXR_SIZE \
+ + MPSC_TXB_SIZE + dma_get_cache_alignment() /* for alignment */)
/* Rx and Tx Ring entry descriptors -- assume entry size is <= cacheline size
*/
struct mpsc_rx_desc {
@@ -266,8 +265,8 @@ struct mpsc_port_info *mpsc_device_remove(int index);
#defineSDMA_DESC_CMDSTAT_EI(1<<23)
#defineSDMA_DESC_CMDSTAT_O (1<<31)
-#define SDMA_DESC_DFLT (SDMA_DESC_CMDSTAT_O | \
- SDMA_DESC_CMDSTAT_EI)
+#define SDMA_DESC_DFLT (SDMA_DESC_CMDSTAT_O \
+ | SDMA_DESC_CMDSTAT_EI)
#defineSDMA_SDC_RFT(1<<0)
#defineSDMA_SDC_SFM(1<<1)
@@ -291,10 +290,10 @@ struct mpsc_port_info *mpsc_device_remove(int index);
#defineSDMA_1_CAUSE_TXBUF (1<<10)
#defineSDMA_1_CAUSE_TXEND (1<<11)
-#defineSDMA_CAUSE_RX_MASK (SDMA_0_CAUSE_RXBUF |
SDMA_0_CAUSE_RXERR | \
- SDMA_1_CAUSE_RXBUF | SDMA_1_CAUSE_RXERR)
-#defineSDMA_CAUSE_TX_MASK (SDMA_0_CAUSE_TXBUF |
SDMA_0_CAUSE_TXEND | \
- SDMA_1_CAUSE_TXBUF | SDMA_1_CAUSE_TXEND)
+#defineSDMA_CAUSE_RX_MASK (SDMA_0_CAUSE_RXBUF |
SDMA_0_CAUSE_RXERR \
+ | SDMA_1_CAUSE_RXBUF | SDMA_1_CAUSE_RXERR)
+#defineSDMA_CAUSE_TX_MASK (SDMA_0_CAUSE_TXBUF |
SDMA_0_CAUSE_TXEND \
+ | SDMA_1_CAUSE_TXBUF | SDMA_1_CAUSE_TXEND)
/* SDMA Interrupt registers */
#defineSDMA_INTR_CAUSE 0x
@@ -308,11 +307,11 @@ struct mpsc_port_info *mpsc_device_remove(int index);
* Define how this driver is known to the outside (we've been assigned a
* range on the "Low-density serial ports" major).
*/
-#define MPSC_MAJOR 204
-#define MPSC_MINOR_START 44
-#defineMPSC_DRIVER_NAME"MPSC"
-#defineMPSC_DEV_NAME "ttyMM"
-#defineMPSC_VERSION"1.00"
+#define MPSC_MAJOR 204
+#define MPSC_MINOR_START 44
+#defineMPSC_DRIVER_NAME"MPSC"
+#defineMPSC_DEV_NAME "ttyMM"
+#defineMPSC_VERSION"1.00"
static struct mpsc_port_info mpsc_ports[MPSC_NUM_CTLRS];
static struct mpsc_shared_regs mpsc_shared_regs;
@@ -328,8 +327,7 @@ static void mpsc_release_port(struct uart_port *port);
*
**
*/
-static void
-mpsc_brg_init(struct mpsc_port_info *pi, u32 clk_src)
+static void mpsc_brg_init(struct mpsc_port_info *pi, u32 clk_src)
{
u32 v;
@@ -345,11 +343,9 @@ mpsc_brg_init(struct mpsc_port_info *pi, u32 clk_src)
writel(readl(pi->brg_base + BRG_BTR) & 0x,
pi->brg_base + BRG_BTR);
- return;
}
-static void
-mpsc_brg_enable(struct mpsc_port_info *pi)
+static void mpsc_brg_enable(struct mpsc_port_info *pi)
{
u32 v;
@@ -359,11 +355,9 @@ mpsc_brg_enable(struct mpsc_port_info *pi)
if (pi->mirror_regs)
pi->BRG_BCR_m = v;
writel(v, pi->brg_base + BRG_BCR);
- return;
}
-static void
-mpsc_brg_disable(struct mpsc_port_info *pi)
+static void mpsc_brg_disable(struct mpsc_port_info *pi)
{
u32 v;
@@ -373,21 +367,19 @@ mpsc_brg_disable(struct mpsc_port_info *pi)
if (pi->mirror_regs)
pi->BRG_BCR_m = v;
writel(v, pi->brg_base + BRG_BCR);
- return;
}
-static inline void
-mpsc_set_baudrate(struct mpsc_port_info *pi, u32 baud)
+/*
+ * To set the baud, we adjust the CDV field in the BRG_BCR reg.
+ * From manual: Baud = clk / ((CDV+1)*2) ==> CDV = (clk / (baud*2)) - 1.
+ * However, the input clock is divided by 16 in the MPSC b/c of how
+ * 'MPSC_MMCRH' was set up so we have to divide the 'clk' used in our
+ * calculation by 16 to account for
[PATCH 3/4] serial: MPSC: Remove duplicate SUPPORT_SYSRQ definition
Remove the duplicate definition of SUPPORT_SYSRQ in mpsc driver. Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> --- drivers/serial/mpsc.c |4 1 file changed, 4 deletions(-) diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c index 0d75505..1311433 100644 --- a/drivers/serial/mpsc.c +++ b/drivers/serial/mpsc.c @@ -74,10 +74,6 @@ #include #include -#if defined(CONFIG_SERIAL_MPSC_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) -#define SUPPORT_SYSRQ -#endif - #defineMPSC_NUM_CTLRS 2 /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] serial: MPSC: Stop rx engine when CREAD cleared
From: Stephane Chazelas <[EMAIL PROTECTED]>
Currently, the MPSC driver doesn't stop recieving characters when the
CREAD flag in termios->c_cflag is cleared. It should. Also, only start
receiving if its not already started.
Signed-off-by: Stephane Chazelas <[EMAIL PROTECTED]>
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
drivers/serial/mpsc.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c
index 99715fe..108fa4c 100644
--- a/drivers/serial/mpsc.c
+++ b/drivers/serial/mpsc.c
@@ -1536,7 +1536,6 @@ mpsc_set_termios(struct uart_port *port, struct ktermios
*termios,
mpsc_set_baudrate(pi, baud);
/* Characters/events to read */
- pi->rcv_data = 1;
pi->port.read_status_mask = SDMA_DESC_CMDSTAT_OR;
if (termios->c_iflag & INPCK)
@@ -1560,11 +1559,15 @@ mpsc_set_termios(struct uart_port *port, struct
ktermios *termios,
pi->port.ignore_status_mask |= SDMA_DESC_CMDSTAT_OR;
}
- /* Ignore all chars if CREAD not set */
- if (!(termios->c_cflag & CREAD))
+ if ((termios->c_cflag & CREAD)) {
+ if (!pi->rcv_data) {
+ pi->rcv_data = 1;
+ mpsc_start_rx(pi);
+ }
+ } else if (pi->rcv_data) {
+ mpsc_stop_rx(port);
pi->rcv_data = 0;
- else
- mpsc_start_rx(pi);
+ }
spin_unlock_irqrestore(&pi->port.lock, flags);
return;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] serial: MPSC: Remove race between Rx stop & restart
From: Carlos Sanchez <[EMAIL PROTECTED]>
The patch in commit ID f7232056bff5fe2d3bfeab35252a66ebaeb5bbde
stops (aborts) the MPSC's receive engine just before restarting it.
Unfortunately, it doesn't wait for the abort to complete before
restarting it which creates a race between the abort and the restart.
If the restart occurs first, the in-progress abort stops it again
and the rx engine remains stopped.
Instead, do the abort when the SDMA engine is being stopped. Make
sure to wait for the abort to complete before continuing.
Signed-off-by: Carlos Sanchez <[EMAIL PROTECTED]>
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
drivers/serial/mpsc.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c
index 00924fe..567fa78 100644
--- a/drivers/serial/mpsc.c
+++ b/drivers/serial/mpsc.c
@@ -1363,8 +1363,6 @@ mpsc_start_rx(struct mpsc_port_info *pi)
{
pr_debug("mpsc_start_rx[%d]: Starting...\n", pi->port.line);
- /* Issue a Receive Abort to clear any receive errors */
- writel(MPSC_CHR_2_RA, pi->mpsc_base + MPSC_CHR_2);
if (pi->rcv_data) {
mpsc_enter_hunt(pi);
mpsc_sdma_cmd(pi, SDMA_SDCM_ERD);
@@ -1379,6 +1377,20 @@ mpsc_stop_rx(struct uart_port *port)
pr_debug("mpsc_stop_rx[%d]: Stopping...\n", port->line);
+ if (pi->mirror_regs) {
+ writel(pi->MPSC_CHR_2_m | MPSC_CHR_2_RA,
+ pi->mpsc_base + MPSC_CHR_2);
+ /* Erratum prevents reading CHR_2 so just delay for a while */
+ udelay(100);
+ }
+ else {
+ writel(readl(pi->mpsc_base + MPSC_CHR_2) | MPSC_CHR_2_RA,
+ pi->mpsc_base + MPSC_CHR_2);
+
+ while (readl(pi->mpsc_base + MPSC_CHR_2) & MPSC_CHR_2_RA)
+ udelay(10);
+ }
+
mpsc_sdma_cmd(pi, SDMA_SDCM_AR);
return;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] serial: Clear proper MPSC interrupt cause bits
From: Jay Lubomirski <[EMAIL PROTECTED]> The interrupt clearing code in mpsc_sdma_intr_ack() mistakenly clears the interrupt for both controllers instead of just the one its supposed to. This can result in the other controller appearing to hang because its interrupt was effectively lost. So, don't clear the interrupt cause bits for both MPSC controllers when clearing the interrupt for one of them. Just clear the one that is supposed to be cleared. Signed-off-by: Jay Lubomirski <[EMAIL PROTECTED]> Acked-by: Mark A. Greer <[EMAIL PROTECTED]> --- Please add this to 2.6.21.x and 2.6.22-rc6, if its not too late. drivers/serial/mpsc.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c index d09f209..00924fe 100644 --- a/drivers/serial/mpsc.c +++ b/drivers/serial/mpsc.c @@ -503,7 +503,8 @@ mpsc_sdma_intr_ack(struct mpsc_port_info *pi) if (pi->mirror_regs) pi->shared_regs->SDMA_INTR_CAUSE_m = 0; - writel(0, pi->shared_regs->sdma_intr_base + SDMA_INTR_CAUSE); + writeb(0x00, pi->shared_regs->sdma_intr_base + SDMA_INTR_CAUSE + + pi->port.line); return; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: Clear proper MPSC interrupt cause bits
On Sat, Jun 23, 2007 at 09:51:44AM -0700, Andrew Morton wrote: > > On Thu, 21 Jun 2007 19:32:08 -0700 "Mark A. Greer" <[EMAIL PROTECTED]> > > wrote: > > From: Jay Lubomirski <[EMAIL PROTECTED]> > > > > Don't clobber the interrupt cause bits for both MPSC controllers when > > clearing the interrupt for one of them. Just clear the one that is > > supposed to be cleared. > > > > Signed-off-by: Jay Lubomirski <[EMAIL PROTECTED]> > > Acked-by: Mark A. Greer <[EMAIL PROTECTED]> > > --- > > drivers/serial/mpsc.c |3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c > > index d09f209..00924fe 100644 > > --- a/drivers/serial/mpsc.c > > +++ b/drivers/serial/mpsc.c > > @@ -503,7 +503,8 @@ mpsc_sdma_intr_ack(struct mpsc_port_info *pi) > > > > if (pi->mirror_regs) > > pi->shared_regs->SDMA_INTR_CAUSE_m = 0; > > - writel(0, pi->shared_regs->sdma_intr_base + SDMA_INTR_CAUSE); > > + writeb(0x00, pi->shared_regs->sdma_intr_base + SDMA_INTR_CAUSE + > > + pi->port.line); > > return; > > } > > In my naive little mpscless bubbleworld, I am believing that this is a > pretty important fix, and that people in an mpscful world might want it in > 2.6.22. And even in 2.6.21.x. Yes, that's probably true although the timing has to be just right for it to occurs so its not that frequent. I don't know what I have to do to get it into 2.6.22 at this late moment (or 2.6.21.x for that matter). > But alas, that's just a guess, which was forced upon me by the lack of > suitable information in your changelog. My aplogies. > So please, tell us what are the real-world consequences of your patch (or > the lack of it), thanks. I'll resubmit the patch with a better description momentarily. Sorry for the hassle. Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] serial: Clear proper MPSC interrupt cause bits
From: Jay Lubomirski <[EMAIL PROTECTED]> Don't clobber the interrupt cause bits for both MPSC controllers when clearing the interrupt for one of them. Just clear the one that is supposed to be cleared. Signed-off-by: Jay Lubomirski <[EMAIL PROTECTED]> Acked-by: Mark A. Greer <[EMAIL PROTECTED]> --- drivers/serial/mpsc.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c index d09f209..00924fe 100644 --- a/drivers/serial/mpsc.c +++ b/drivers/serial/mpsc.c @@ -503,7 +503,8 @@ mpsc_sdma_intr_ack(struct mpsc_port_info *pi) if (pi->mirror_regs) pi->shared_regs->SDMA_INTR_CAUSE_m = 0; - writel(0, pi->shared_regs->sdma_intr_base + SDMA_INTR_CAUSE); + writeb(0x00, pi->shared_regs->sdma_intr_base + SDMA_INTR_CAUSE + + pi->port.line); return; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rtc: add rtc-m41txx driver
On Wed, Jun 20, 2007 at 12:59:26AM +0900, Atsushi Nemoto wrote: > This is a new-style i2c driver for ST M41TXX RTC chip, derived from > works by Alexander Bigga <[EMAIL PROTECTED]> who wrote the original > rtc-m41txx.c based on drivers/i2c/chips/m41t00.c driver. > > This driver supports M41T80, M41T81 and M41ST85. The old m41t00 > driver supports M41T00, M41T81 and M41T85(M41ST85). While the M41T00 > chip is now supported by rtc-ds1307 driver, this driver does not > include support for the chip. > > Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]> > Signed-off-by: Alexander Bigga <[EMAIL PROTECTED]> Other than addressing David's question about alarm support, Acked-by: Mark A. Greer <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
Bartlomiej Zolnierkiewicz wrote:
Thanks, I see that you did global replacement of __devinit
by __init and __devexit by __exit - it seems correct *only* if:
- there can be only one i2c controller in the system
- there can be only one host bridge in the system
- i2c core calls ->probe only once during driver init
and ->remove only once during driver exit
If all conditions are really true some comment about
this in the code would still be be nice.
You're right. The 'dev' is back except on the module_init/exit routines.
While at it more silly, minor nitpicking ;)
+static void
+mv64xxx_i2c_wait_for_completion(struct mv64xxx_i2c_data *drv_data)
+{
+ longflags, time_left;
'flags' are of 'unsigned long' not 'long' type
Fixed.
there is no need for explicit return in void functions
I can't find any definitive policy on this. I kind of like the explicit
return, I don't know why. I've had others make the same comment,
though, so I'll remove them since it obviously bothers people.
Attached is a replacement patch.
Thanks again, Bartlomiej.
Mark
--
Marvell makes a line of host bridge for PPC and MIPS systems. On those
bridges is an i2c controller. This patch adds the driver for that i2c
controller.
Please apply.
Depends on patch submitted by Jean Delvare:
http://archives.andrew.net.au/lm-sensors/msg29405.html
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-02-09 14:32:24 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-02-09 14:32:24 -07:00
@@ -486,4 +486,14 @@
This driver can also be built as a module. If so, the module
will be called i2c-pca-isa.
+config I2C_MV64XXX
+ tristate "Marvell mv64xxx I2C Controller"
+ depends on I2C && MV64X60 && EXPERIMENTAL
+ help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mv64xxx.
+
endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile 2005-02-09 14:32:24 -07:00
+++ b/drivers/i2c/busses/Makefile 2005-02-09 14:32:24 -07:00
@@ -21,6 +21,7 @@
obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
obj-$(CONFIG_I2C_KEYWEST) += i2c-keywest.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-02-09 14:32:24 -07:00
@@ -0,0 +1,596 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ *
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register defines */
+#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
+#defineMV64XXX_I2C_REG_DATA0x04
+#defineMV64XXX_I2C_REG_CONTROL 0x08
+#defineMV64XXX_I2C_REG_STATUS 0x0c
+#defineMV64XXX_I2C_REG_BAUD0x0c
+#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
+#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
+
+#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
+#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
+#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
+#defineMV64XXX_I2C_REG_CONTROL_START 0x0020
+#defineMV64XXX_I2C_REG_CONTROL_TWSIEN 0x0040
+#defineMV64XXX_I2C_REG_CONTROL_INTEN 0x0080
+
+/* Ctlr status values */
+#defineMV64XXX_I2C_STATUS_BUS_ERR 0x00
+#defineMV64XXX_I2C_STATUS_MAST_START 0x08
+#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
+#defineMV64XXX_I2C_STATUS_MAST_WR_ACK 0x2
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
Bartlomiej Zolnierkiewicz wrote:
Hi,
just a minor thing
+static int __devinit
+mv64xxx_i2c_init(void)
+{
+ return driver_register(&mv64xxx_i2c_driver);
+}
__init
+static void __devexit
+mv64xxx_i2c_exit(void)
+{
+ driver_unregister(&mv64xxx_i2c_driver);
+ return;
+}
__exit
these functions relate to module not device
Gahhh. Thanks Bartlomiej.
Below is yet another replacement patch
--
Marvell makes a line of host bridge for PPC and MIPS systems. On those
bridges is an i2c controller. This patch adds the driver for that i2c
controller.
Please apply.
Depends on patch submitted by Jean Delvare:
http://archives.andrew.net.au/lm-sensors/msg29405.html
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-02-08 17:28:52 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-02-08 17:28:52 -07:00
@@ -486,4 +486,14 @@
This driver can also be built as a module. If so, the module
will be called i2c-pca-isa.
+config I2C_MV64XXX
+ tristate "Marvell mv64xxx I2C Controller"
+ depends on I2C && MV64X60 && EXPERIMENTAL
+ help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mv64xxx.
+
endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile 2005-02-08 17:28:52 -07:00
+++ b/drivers/i2c/busses/Makefile 2005-02-08 17:28:52 -07:00
@@ -21,6 +21,7 @@
obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
obj-$(CONFIG_I2C_KEYWEST) += i2c-keywest.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-02-08 17:28:52 -07:00
@@ -0,0 +1,606 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ *
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register defines */
+#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
+#defineMV64XXX_I2C_REG_DATA0x04
+#defineMV64XXX_I2C_REG_CONTROL 0x08
+#defineMV64XXX_I2C_REG_STATUS 0x0c
+#defineMV64XXX_I2C_REG_BAUD0x0c
+#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
+#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
+
+#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
+#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
+#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
+#defineMV64XXX_I2C_REG_CONTROL_START 0x0020
+#defineMV64XXX_I2C_REG_CONTROL_TWSIEN 0x0040
+#defineMV64XXX_I2C_REG_CONTROL_INTEN 0x0080
+
+/* Ctlr status values */
+#defineMV64XXX_I2C_STATUS_BUS_ERR 0x00
+#defineMV64XXX_I2C_STATUS_MAST_START 0x08
+#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
+#defineMV64XXX_I2C_STATUS_MAST_WR_ACK 0x28
+#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK 0x30
+#defineMV64XXX_I2C_STATUS_MAST_LOST_ARB0x38
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_NO_ACK 0x48
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_ACK 0x50
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_NO_ACK 0x58
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK 0xd0
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK0xd8
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_ACK 0xe0
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK0xe8
+#defineMV64XXX_I2C_STAT
[PATCH][I2C] Marvell mv64xxx i2c driver
Marvell makes a line of host bridge for PPC and MIPS systems. On those
bridges is an i2c controller. This patch adds the driver for that i2c
controller.
Please apply.
Depends on patch submitted by Jean Delvare:
http://archives.andrew.net.au/lm-sensors/msg29405.html
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
[Note: This patch is a *replacement* patch]
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-02-08 16:24:33 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-02-08 16:24:33 -07:00
@@ -486,4 +486,14 @@
This driver can also be built as a module. If so, the module
will be called i2c-pca-isa.
+config I2C_MV64XXX
+ tristate "Marvell mv64xxx I2C Controller"
+ depends on I2C && MV64X60 && EXPERIMENTAL
+ help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mv64xxx.
+
endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile 2005-02-08 16:24:33 -07:00
+++ b/drivers/i2c/busses/Makefile 2005-02-08 16:24:33 -07:00
@@ -21,6 +21,7 @@
obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
obj-$(CONFIG_I2C_KEYWEST) += i2c-keywest.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-02-08 16:24:33 -07:00
@@ -0,0 +1,606 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ *
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register defines */
+#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
+#defineMV64XXX_I2C_REG_DATA0x04
+#defineMV64XXX_I2C_REG_CONTROL 0x08
+#defineMV64XXX_I2C_REG_STATUS 0x0c
+#defineMV64XXX_I2C_REG_BAUD0x0c
+#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
+#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
+
+#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
+#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
+#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
+#defineMV64XXX_I2C_REG_CONTROL_START 0x0020
+#defineMV64XXX_I2C_REG_CONTROL_TWSIEN 0x0040
+#defineMV64XXX_I2C_REG_CONTROL_INTEN 0x0080
+
+/* Ctlr status values */
+#defineMV64XXX_I2C_STATUS_BUS_ERR 0x00
+#defineMV64XXX_I2C_STATUS_MAST_START 0x08
+#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
+#defineMV64XXX_I2C_STATUS_MAST_WR_ACK 0x28
+#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK 0x30
+#defineMV64XXX_I2C_STATUS_MAST_LOST_ARB0x38
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_NO_ACK 0x48
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_ACK 0x50
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_NO_ACK 0x58
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK 0xd0
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK0xd8
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_ACK 0xe0
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK0xe8
+#defineMV64XXX_I2C_STATUS_NO_STATUS0xf8
+
+/* Driver states */
+enum {
+ MV64XXX_I2C_STATE_INVALID,
+ MV64XXX_I2C_STATE_IDLE,
+ MV64XXX_I2C_STATE_WAITING_FOR_START_COND,
+ MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK,
+ MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK,
+ MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_ACK,
+ MV64XXX_I2C_STATE_WAITING_FO
Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver
Greg KH wrote:
Can you resend it with a proper Changelog description in the top of the
email and the signed-off-by line? thanks,
greg k-h
Certainly.
--
This patch adds support for the ST M41T00 I2C RTC chip.
This rtc chip has no mechanism to freeze it's registers while being
read; however, it will delay updating the external values of the
registers for 250ms after a register is read. To ensure that a sane
time value is read, the driver verifies that the same registers values
were read twice before returning.
Also, when setting the rtc from an interrupt handler, a tasklet is used
to provide the context required by the i2c core code.
Please apply.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
--- a/drivers/i2c/chips/Kconfig 2005-02-04 17:00:45 -07:00
+++ b/drivers/i2c/chips/Kconfig 2005-02-04 17:00:45 -07:00
@@ -371,4 +371,13 @@
This driver can also be built as a module. If so, the module
will be called isp1301_omap.
+config SENSORS_M41T00
+ tristate "ST M41T00 RTC chip"
+ depends on I2C && PPC32
+ help
+ If you say yes here you get support for the ST M41T00 RTC chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called m41t00.
+
endmenu
diff -Nru a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
--- a/drivers/i2c/chips/Makefile2005-02-04 17:00:45 -07:00
+++ b/drivers/i2c/chips/Makefile2005-02-04 17:00:45 -07:00
@@ -26,6 +26,7 @@
obj-$(CONFIG_SENSORS_LM87) += lm87.o
obj-$(CONFIG_SENSORS_LM90) += lm90.o
obj-$(CONFIG_SENSORS_MAX1619) += max1619.o
+obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
diff -Nru a/drivers/i2c/chips/m41t00.c b/drivers/i2c/chips/m41t00.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/chips/m41t00.c2005-02-04 17:00:45 -07:00
@@ -0,0 +1,247 @@
+/*
+ * drivers/i2c/chips/m41t00.c
+ *
+ * I2C client/driver for the ST M41T00 Real-Time Clock chip.
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+/*
+ * This i2c client/driver wedges between the drivers/char/genrtc.c RTC
+ * interface and the SMBus interface of the i2c subsystem.
+ * It would be more efficient to use i2c msgs/i2c_transfer directly but, as
+ * recommened in .../Documentation/i2c/writing-clients section
+ * "Sending and receiving", using SMBus level communication is preferred.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#defineM41T00_DRV_NAME "m41t00"
+
+static DECLARE_MUTEX(m41t00_mutex);
+
+static struct i2c_driver m41t00_driver;
+static struct i2c_client *save_client;
+
+static unsigned short ignore[] = { I2C_CLIENT_END };
+static unsigned short normal_addr[] = { 0x68, I2C_CLIENT_END };
+
+static struct i2c_client_address_data addr_data = {
+ .normal_i2c = normal_addr,
+ .normal_i2c_range = ignore,
+ .probe = ignore,
+ .probe_range= ignore,
+ .ignore = ignore,
+ .ignore_range = ignore,
+ .force = ignore,
+};
+
+ulong
+m41t00_get_rtc_time(void)
+{
+ s32 sec, min, hour, day, mon, year;
+ s32 sec1, min1, hour1, day1, mon1, year1;
+ ulong limit = 10;
+
+ sec = min = hour = day = mon = year = 0;
+ sec1 = min1 = hour1 = day1 = mon1 = year1 = 0;
+
+ down(&m41t00_mutex);
+ do {
+ if (((sec = i2c_smbus_read_byte_data(save_client, 0)) >= 0)
+ && ((min = i2c_smbus_read_byte_data(save_client, 1))
+ >= 0)
+ && ((hour = i2c_smbus_read_byte_data(save_client, 2))
+ >= 0)
+ && ((day = i2c_smbus_read_byte_data(save_client, 4))
+ >= 0)
+ && ((mon = i2c_smbus_read_byte_data(save_client, 5))
+ >= 0)
+ && ((year = i2c_smbus_read_byte_data(save_client, 6))
+ >= 0)
+ && ((sec == sec1) && (min == min1) && (hour == hour1)
+ && (day == day1) && (mon == mon1)
+ && (year == year1)))
+
+ break;
+
+ sec1 = sec;
+ min1 = m
Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver
From http://archives.andrew.net.au/lm-sensors/msg29319.html: Mark A. Greer wrote: Here is a replacement patch that should address Jean Delvare and Dick Johnson's issues. Please let me know if there are any more issues. Thanks, Mark Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> -- I haven't heard of any more problems so can I get this patch applied? Thanks, Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
Alexey Dobriyan wrote: On Thursday 03 February 2005 21:12, Mark A. Greer wrote: + mv64xxx_i2c_fsm(drv_data, status); It can set drv_data->rc to -ENODEV or -EIO. In both cases ->action goes to MV64XXX_I2C_ACTION_SEND_STOP and mv64xxx_i2c_do_action() will writel() something. Is it correct to _not_ check ->rc here? I think so. It still needs to go into do_action even when rc != 0 (in which case it'll do a STOP condition). Ok. Thanks for the explanation. Agree, ->rc should be left as is. Okay. --- a/include/linux/i2c-id.h +++ b/include/linux/i2c-id.h + /* 0x17 - USB */ + /* 0x18 - Virtual buses */ +#define I2C_ALGO_MV64XXX 0x19 /* Marvell mv64xxx i2c ctlr */ While I searched for typos and you're fixing them, au1550 owned 0x17. 2.6.11-rc3 says: #define I2C_ALGO_AU1550 0x17 /* Au1550 PSC algorithm */ So, I'd remove first two comments. I added the comments b/c of this email from Jean Delvare, http://www.uwsg.iu.edu/hypermail/linux/kernel/0501.3/0977.html. The relevant part being: "0x17 is reserved within the legacy i2c project for an USB algorithm, and 0x18 for virtual busses. Could you please use 0x19 instead, so as to avoid future collisions?" It looks like I2C_ALGO_AU1550 was just added so my guess is Jean is correct and I2C_ALGO_AU1550 should be made 0x1a (or I move mine back one). Would someone confirm that 0x17 is used by legacy i2c stuffs? I don't really know where to look. If so, I can easily make a patch moving it back. Oh, and the last note: current sparse and gcc 4 don't produce any warnings. Cool! Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
Hi, Alexey.
--
Alexey Dobriyan wrote:
On Wednesday 02 February 2005 19:26, Mark A. Greer wrote:
How's this (a complete replacement for previous patch)?
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges
Dot at the end. Should have noticed it earlier...
Gahh, I noticed that too a while back. I thought I'd fixed it... Done.
+ if (drv_data->state == MV64XXX_I2C_STATE_IDLE) {
+ drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
+ drv_data->state = MV64XXX_I2C_STATE_IDLE;
drv_data->state is already MV64XXX_I2C_STATE_IDLE. Gcc will probably
optimize
this line away, but...
Done away with.
+ }
+ else {
It should be "} else {" according to CodingStyle.
Done.
+static int
+mv64xxx_i2c_intr(int irq, void *dev_id, struct pt_regs *regs)
+ while (readl(drv_data->reg_base + MV64XXX_I2C_REG_CONTROL) &
+ MV64XXX_I2C_REG_CONTROL_IFLG) {
+ status = readl(drv_data->reg_base + MV64XXX_I2C_REG_STATUS);
+ mv64xxx_i2c_fsm(drv_data, status);
It can set drv_data->rc to -ENODEV or -EIO. In both cases ->action goes to
MV64XXX_I2C_ACTION_SEND_STOP and mv64xxx_i2c_do_action() will writel()
something. Is it correct to _not_ check ->rc here?
I think so. It still needs to go into do_action even when rc != 0 (in
which case it'll do a STOP condition).
If it isn't then would it be
better to make all functions that set it return -E___ instead and drop
struct mv64xxx_i2c_data.rc altogether?
I may not be understanding what you mean but I think I need something
like mv64xxx_i2c_data.rc or a plain old global to hang onto the return
code. I need that so when the wait_event_interruptible_timeout()
returns, that thread can find out what happened while it was blocked.
This is what I mean:
- calling thread enters i2c_xfer
- eventually the initial i2c action is executed and the thread blocks in
wait_event_interruptible_timeout()
- other processes run
- several interrupts happen, last one causing an error which is stored
in mv64xxx_i2c_data.rc
- do_action issues a stop on the i2c bus
- thread is unblocked and now has to dig out the rc from mv64xxx_i2c_data.rc
Or am I not understanding what you mean?
+
+ if (!time_left <= 0) {
Confusing. You meant "if (time_left)" or "if (time_left > 0)"?
No, I'm blind. I meant "if (time_left <=0)". Should be fixed now.
Good catch.
+static struct i2c_algorithm mv64xxx_i2c_algo = {
+ .name = MV64XXX_I2C_CTLR_NAME "algorithm",
MV64XXX_I2C_CTLR_NAME doesn't end with space. " algorithm" here.
Space added.
+ dev_err(dev, "mv64xxx: Can't register intr handler "
+ "irq: %d\\n", drv_data->irq);
You snipped s# \\n # \n # suggestion in my previous email. ;-)
Ah, got it this time. :)
This patch is a replacement patch that should address your concerns
except maybe the mv64xxx_i2c_data.rc one.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-02-03 12:10:35 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-02-03 12:10:35 -07:00
@@ -476,4 +476,14 @@
This driver can also be built as a module. If so, the module
will be called i2c-pca-isa.
+config I2C_MV64XXX
+ tristate "Marvell mv64xxx I2C Controller"
+ depends on I2C && MV64X60 && EXPERIMENTAL
+ help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mv64xxx.
+
endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile 2005-02-03 12:10:35 -07:00
+++ b/drivers/i2c/busses/Makefile 2005-02-03 12:10:35 -07:00
@@ -20,6 +20,7 @@
obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
obj-$(CONFIG_I2C_KEYWEST) += i2c-keywest.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-02-03 12:10:35 -07:00
@@ -0,0 +1,606 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ *
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
Alexey Dobriyan wrote:
On Tue, 01 Feb 2005 10:54:32 -0700, Mark A. Greer wrote:
+struct mv64xxx_i2c_data {
+ void *reg_base;
ioremap() returns "void __iomem *".
Okay.
+static void __devexit
+mv64xxx_i2c_unmap_regs(struct mv64xxx_i2c_data *drv_data)
+{
+ if (!drv_data->reg_base) {
+ iounmap(drv_data->reg_base);
A typo? You're unmapping known to be invalid address.
Yes, a typo. Good catch.
+ drv_data->reg_base = 0;
Use NULL because drv_data->reg_base is a pointer.
Done.
+ if ((pd->id == 0) && pdata) {
Rewrite this as:
if ((pd->id != 0) || !pdata)
return -ENODEV;
and save one level of indentation below.
Done.
Done.
Alexey
P. S.: struct mv64xxx_i2c_data revisited...
+ uint state;
+ ulong reg_base_p;
Silly request, but... Maybe this should be changed to plain old "unsigned
int"
and "unsigned long". Please. I just don't understand why people use "uint",
"u_int", "uInt", "UINT", "uINT", "uint_t" which are always typedef'ed to
"unsigned int".
Thanks Alexey & Greg. How's this (a complete replacement for previous
patch)?
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-02-02 10:24:30 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-02-02 10:24:30 -07:00
@@ -476,4 +476,14 @@
This driver can also be built as a module. If so, the module
will be called i2c-pca-isa.
+config I2C_MV64XXX
+ tristate "Marvell mv64xxx I2C Controller"
+ depends on I2C && MV64X60 && EXPERIMENTAL
+ help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mv64xxx.
+
endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile 2005-02-02 10:24:30 -07:00
+++ b/drivers/i2c/busses/Makefile 2005-02-02 10:24:30 -07:00
@@ -20,6 +20,7 @@
obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
obj-$(CONFIG_I2C_KEYWEST) += i2c-keywest.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-02-02 10:24:30 -07:00
@@ -0,0 +1,615 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ *
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register defines */
+#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
+#defineMV64XXX_I2C_REG_DATA0x04
+#defineMV64XXX_I2C_REG_CONTROL 0x08
+#defineMV64XXX_I2C_REG_STATUS 0x0c
+#defineMV64XXX_I2C_REG_BAUD0x0c
+#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
+#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
+
+#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
+#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
+#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
+#defineMV64XXX_I2C_REG_CONTROL_START 0x0020
+#defineMV64XXX_I2C_REG_CONTROL_TWSIEN 0x0040
+#defineMV64XXX_I2C_REG_CONTROL_INTEN 0x0080
+
+/* Ctlr status values */
+#defineMV64XXX_I2C_STATUS_BUS_ERR 0x00
+#defineMV64XXX_I2C_STATUS_MAST_START 0x08
+#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
+#defineMV64XXX_I2C_STATUS_MAST_WR_ACK 0x28
+#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK 0x30
+#defineM
Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver
Thank you for your comments, Jean.
Jean Delvare wrote:
Hi Mark,
+ This driver can also be built as a module. If so, the module
+ will be called i2c-m41t00.
It'll actually be called m41t00, according to the Makefile.
Good catch.
+struct m41t00_data {
+ struct i2c_client client;
+};
You don't have to do that. Including the i2c_client stucture in the data
structure is a trick which let us get both allocated with a single
kmalloc (and freed with a single kfree) while still respecting the
arch-dependent alignment requirements. If you have no private data to
carry around, you can do the kmalloc on the i2c_client structure
directly, and have client->data point to NULL (which it actually already
does thanks to memset). This will save some code in both the detection
and the detach functions.
However, if you know that, in a future update of this driver, you *will*
have to store client-private data, then I guess you can keep it this way.
Its gone.
+ i2c_detach_client(client);
This one supposedly can fail.
Okay, I'll check.
+ .name = "M41T00",
No caps in name please (will be used in sysfs).
Done.
+static int __devinit
+m41t00_init(void)
+{
+ return i2c_add_driver(&m41t00_driver);
+}
+static void __devexit
+m41t00_exit(void)
+{
+ i2c_del_driver(&m41t00_driver);
+ return;
+}
Should be __init and __exit, respectively, unless I am mistaken. And the
last return is usless.
I thought the __devxxx ones were the best ones to use but I don't know
for sure. I'll change them to __init/__exit.
I'm also suspicious about the other __devexit and __devinit you used. No
other i2c chip drivers has them.
Done.
Here is a replacement patch that should address Jean Delvare and Dick
Johnson's issues. Please let me know if there are any more issues.
Thanks,
Mark
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
--- a/drivers/i2c/chips/Kconfig 2005-02-01 13:37:08 -07:00
+++ b/drivers/i2c/chips/Kconfig 2005-02-01 13:37:08 -07:00
@@ -371,4 +371,13 @@
This driver can also be built as a module. If so, the module
will be called isp1301_omap.
+config SENSORS_M41T00
+ tristate "ST M41T00 RTC chip"
+ depends on I2C && PPC32
+ help
+ If you say yes here you get support for the ST M41T00 RTC chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called m41t00.
+
endmenu
diff -Nru a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
--- a/drivers/i2c/chips/Makefile2005-02-01 13:37:08 -07:00
+++ b/drivers/i2c/chips/Makefile2005-02-01 13:37:08 -07:00
@@ -26,6 +26,7 @@
obj-$(CONFIG_SENSORS_LM87) += lm87.o
obj-$(CONFIG_SENSORS_LM90) += lm90.o
obj-$(CONFIG_SENSORS_MAX1619) += max1619.o
+obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
diff -Nru a/drivers/i2c/chips/m41t00.c b/drivers/i2c/chips/m41t00.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/chips/m41t00.c2005-02-01 13:37:08 -07:00
@@ -0,0 +1,247 @@
+/*
+ * drivers/i2c/chips/m41t00.c
+ *
+ * I2C client/driver for the ST M41T00 Real-Time Clock chip.
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+/*
+ * This i2c client/driver wedges between the drivers/char/genrtc.c RTC
+ * interface and the SMBus interface of the i2c subsystem.
+ * It would be more efficient to use i2c msgs/i2c_transfer directly but, as
+ * recommened in .../Documentation/i2c/writing-clients section
+ * "Sending and receiving", using SMBus level communication is preferred.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#defineM41T00_DRV_NAME "m41t00"
+
+static DECLARE_MUTEX(m41t00_mutex);
+
+static struct i2c_driver m41t00_driver;
+static struct i2c_client *save_client;
+
+static unsigned short ignore[] = { I2C_CLIENT_END };
+static unsigned short normal_addr[] = { 0x68, I2C_CLIENT_END };
+
+static struct i2c_client_address_data addr_data = {
+ .normal_i2c = normal_addr,
+ .normal_i2c_range = ignore,
+ .probe = ignore,
+ .probe_range= ignore,
+ .ignore = ignore,
+ .ignore_range = ignore,
+ .force = ignore,
+};
+
+ulong
+m41t00_get_rtc_time(void)
+{
+ s32 sec, min, hour, day, mon, year;
+ s32 sec1, min1, hour1, day1, mon1, year1;
+ ulong limit = 10;
+
+
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
Greg KH wrote:
How about a whole new patch that I could apply? That would be better :)
Oops, sorry. :)
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-02-01 10:45:00 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-02-01 10:45:00 -07:00
@@ -476,4 +476,14 @@
This driver can also be built as a module. If so, the module
will be called i2c-pca-isa.
+config I2C_MV64XXX
+ tristate "Marvell mv64xxx I2C Controller"
+ depends on I2C && MV64X60 && EXPERIMENTAL
+ help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mv64xxx.
+
endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile 2005-02-01 10:45:00 -07:00
+++ b/drivers/i2c/busses/Makefile 2005-02-01 10:45:00 -07:00
@@ -20,6 +20,7 @@
obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
obj-$(CONFIG_I2C_KEYWEST) += i2c-keywest.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-02-01 10:45:00 -07:00
@@ -0,0 +1,614 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ *
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register defines */
+#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
+#defineMV64XXX_I2C_REG_DATA0x04
+#defineMV64XXX_I2C_REG_CONTROL 0x08
+#defineMV64XXX_I2C_REG_STATUS 0x0c
+#defineMV64XXX_I2C_REG_BAUD0x0c
+#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
+#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
+
+#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
+#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
+#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
+#defineMV64XXX_I2C_REG_CONTROL_START 0x0020
+#defineMV64XXX_I2C_REG_CONTROL_TWSIEN 0x0040
+#defineMV64XXX_I2C_REG_CONTROL_INTEN 0x0080
+
+/* Ctlr status values */
+#defineMV64XXX_I2C_STATUS_BUS_ERR 0x00
+#defineMV64XXX_I2C_STATUS_MAST_START 0x08
+#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
+#defineMV64XXX_I2C_STATUS_MAST_WR_ACK 0x28
+#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK 0x30
+#defineMV64XXX_I2C_STATUS_MAST_LOST_ARB0x38
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_NO_ACK 0x48
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_ACK 0x50
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_NO_ACK 0x58
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK 0xd0
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK0xd8
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_ACK 0xe0
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK0xe8
+#defineMV64XXX_I2C_STATUS_NO_STATUS0xf8
+
+/* Driver states */
+enum {
+ MV64XXX_I2C_STATE_INVALID,
+ MV64XXX_I2C_STATE_IDLE,
+ MV64XXX_I2C_STATE_WAITING_FOR_START_COND,
+ MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK,
+ MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK,
+ MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_ACK,
+ MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_DATA,
+ MV64XXX_I2C_STATE_ABORTING,
+};
+
+/* Driver actions */
+enum {
+ MV64XXX_I2C_ACTION_INVALID,
+ MV64XXX_I2C_ACTION_CONTINUE,
+ MV64XXX_I2C_ACTION_SEND_START,
+ MV64XXX_I2C_ACTION_SEND_ADDR_1,
+ MV64XXX_I2C_ACTION_SEND_AD
Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver
linux-os wrote: On ix86 machines, it is appropriate to read the RTC clock several times in a row until nothing changes. This protects against getting bad readings when some values wrap (like seconds). You can't stop the clock when you read it or you will lose time. I don't see anything like this in your code. Also, when setting the clock it is necessary to stop the clock so its settings don't change while you are writing a new time. I also don't see anything like this in your code either. This particular RTC chip provide no mechanism to manually stop the clock for reading or writing. However, when you begin reading the clock registers, it delays updating the externally visible register values for 250ms but contiues to keep time internally so time isn't lost. I can't find anything in the manual WRT updating the clock. There is a problem that if all the register reads don't happen within the 250ms window, it could return a bad value if a register wraps. Unless someone else points out why this is a bad idea, I'll add a loop to ensure the same values were read twice in a row. Also ix86 machines have a spin-lock, rtc_lock, so that other procedures, even interrupts can access its registers. I see you using a semaphore that can't be used in interrupt context. This is an I2C based RTC chip and the I2C subsystem used to access it assumes (AFAICT) that its not called from an interrupt handler (e.g., drivers/i2c/i2c-core.c:i2c_transfer calls() calls down()/up()). So I need to handle an interrupt handler calling this driver which then calls into code that assumes its not in an interrupt handler. That's why the 'set' routine schedules a tasklet if its in an interrupt handler. In ppc, at least, the 'get' routine isn't called from an interrupt so its not an issue. Notice: the RTC clock is used for high-precision timing via interrupt in some ix86 drivers. If you modify the RTC code on all platforms as you propose, you cannot "keep" the RTC all to your self. Its interrupt must be available to drivers and access to the hardware needs to be locked with the existing spin-lock. Hmm, interesting. Note that this RTC doesn't generate an interrupt/initiate an i2c transaction. I note that on 2.6.9 on somebody broke it so that, the interrupt is used for something only ONCE during startup and ONCE during shut-down. CPU0 0:6225448IO-APIC-edge timer 1: 14002IO-APIC-edge i8042 8: 1IO-APIC-edge rtc<--- bingo 9: 0 IO-APIC-level acpi [snipped...] I don't have a clue why anybody would grab that interrupt. Fortunately, the interrupt-grabbing code can be loaded as a module and then unloaded so that other drivers can use that device and its interrupt. Any changes to the RTC code need to consider these things. Okay, thanks for the insight. Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
Greg KH wrote:
On Tue, Jan 25, 2005 at 06:26:45PM -0700, Mark A. Greer wrote:
+static inline void
+mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
This is a much too big of a function to be "inline". Please change it.
Same for your other inline functions, that's not really needed, right?
+{
+ pr_debug("mv64xxx_i2c_fsm: ENTER--state: %d, status: 0x%x\n",
+ drv_data->state, status);
Please use the dev_* calls instead. It gives you an accurate
description of the specific device that emits the messages. Also use it
for all of the printk() calls in the driver too.
thanks,
greg k-h
Certainly. I already posted this [incremental] patch based on your
previous comments,
http://www.ussg.iu.edu/hypermail/linux/kernel/0501.3/0941.html. Is that
better?
Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][I2C] ST M41T00 I2C RTC chip driver
This patch adds support for the ST M41T00 RTC chip.
You will likely notice that it implements a PPC-specific interface
(/dev/rtc->drivers/char/genrtc.h->include/asm-ppc/rtc.h->this file).
This was necessary to support a subset of ppc platforms that need to
hook up the rtc support at runtime. If I implemented /dev/rtc directly
or interfaced to genrtc.c directly, those platforms couldn't use this
driver. Eventually, I hope to work on more uniform rtc support across
all the processor architectures.
Also, on ppc at least, the hw clock can be set from a timer interrupt if
STA_UNSYNC is not set (e.g., ntpd is running). To handle this, a
tasklet is used to set the clock if in_interrupt() is true.
I'd appreciate an comments or to have it pushed into the kernel.org tree
if its acceptable.
Thanks,
Mark
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
--- a/drivers/i2c/chips/Kconfig 2005-01-31 10:33:34 -07:00
+++ b/drivers/i2c/chips/Kconfig 2005-01-31 10:33:34 -07:00
@@ -371,4 +371,13 @@
This driver can also be built as a module. If so, the module
will be called isp1301_omap.
+config SENSORS_M41T00
+ tristate "ST M41T00 RTC chip"
+ depends on I2C && PPC32
+ help
+ If you say yes here you get support for the ST M41T00 RTC chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-m41t00.
+
endmenu
diff -Nru a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
--- a/drivers/i2c/chips/Makefile2005-01-31 10:33:34 -07:00
+++ b/drivers/i2c/chips/Makefile2005-01-31 10:33:34 -07:00
@@ -26,6 +26,7 @@
obj-$(CONFIG_SENSORS_LM87) += lm87.o
obj-$(CONFIG_SENSORS_LM90) += lm90.o
obj-$(CONFIG_SENSORS_MAX1619) += max1619.o
+obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
diff -Nru a/drivers/i2c/chips/m41t00.c b/drivers/i2c/chips/m41t00.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/chips/m41t00.c2005-01-31 10:33:34 -07:00
@@ -0,0 +1,224 @@
+/*
+ * drivers/i2c/chips/m41t00.c
+ *
+ * I2C client/driver for the ST M41T00 Real-Time Clock chip.
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+/*
+ * This i2c client/driver wedges between the drivers/char/genrtc.c RTC
+ * interface and the SMBus interface of the i2c subsystem.
+ * It would be more efficient to use i2c msgs/i2c_transfer directly but, as
+ * recommened in .../Documentation/i2c/writing-clients section
+ * "Sending and receiving", using SMBus level communication is preferred.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static DECLARE_MUTEX(m41t00_mutex);
+
+struct m41t00_data {
+ struct i2c_client client;
+};
+
+static struct i2c_driver m41t00_driver;
+static struct i2c_client *save_client;
+
+static unsigned short ignore[] = { I2C_CLIENT_END };
+static unsigned short normal_addr[] = { 0x68, I2C_CLIENT_END };
+
+static struct i2c_client_address_data addr_data = {
+ .normal_i2c = normal_addr,
+ .normal_i2c_range = ignore,
+ .probe = ignore,
+ .probe_range= ignore,
+ .ignore = ignore,
+ .ignore_range = ignore,
+ .force = ignore,
+};
+
+ulong
+m41t00_get_rtc_time(void)
+{
+ s32 sec, min, hour, day, mon, year;
+
+ down(&m41t00_mutex);
+ if (((sec = i2c_smbus_read_byte_data(save_client, 0)) < 0)
+ || ((min = i2c_smbus_read_byte_data(save_client, 1)) < 0)
+ || ((hour = i2c_smbus_read_byte_data(save_client, 2)) < 0)
+ || ((day = i2c_smbus_read_byte_data(save_client, 4)) < 0)
+ || ((mon = i2c_smbus_read_byte_data(save_client, 5)) < 0)
+ || ((year = i2c_smbus_read_byte_data(save_client, 6)) < 0)) {
+
+ dev_warn(&save_client->dev, "m41t00: can't read rtc chip\n");
+ sec = min = hour = day = mon = year = 0;
+ }
+ up(&m41t00_mutex);
+
+ sec &= 0x7f;
+ min &= 0x7f;
+ hour &= 0x3f;
+ day &= 0x3f;
+ mon &= 0x1f;
+ year &= 0xff;
+
+ BCD_TO_BIN(sec);
+ BCD_TO_BIN(min);
+ BCD_TO_BIN(hour);
+ BCD_TO_BIN(day);
+ BCD_TO_BIN(mon);
+ BCD_TO_BIN(year);
+
+ year += 1900;
+ if (year < 1970)
+ year += 100;
+
+ return mktime(year,
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
Jean Delvare wrote: Hi Mark, Thanks for the commenting, Jean. +config I2C_MV64XXX + tristate "Marvell mv64xxx I2C Controller" + depends on I2C && MV64X60 && EXPERIMENTAL? Yes, I guess that's the correct thing to do. I'll add that. diff -Nru a/include/linux/i2c-id.h b/include/linux/i2c-id.h --- a/include/linux/i2c-id.h2005-01-25 18:15:24 -07:00 +++ b/include/linux/i2c-id.h2005-01-25 18:15:24 -07:00 @@ -200,6 +200,7 @@ #define I2C_ALGO_SIBYTE 0x15 /* Broadcom SiByte SOCs */ #define I2C_ALGO_SGI 0x16/* SGI algorithm*/ +#define I2C_ALGO_MV64XXX 0x17 /* Marvell mv64xxx i2c ctlr */ 0x17 is reserved within the legacy i2c project for an USB algorithm, and 0x18 for virtual busses. Could you please use 0x19 instead, so as to avoid future collisions? Absolutely. I was unaware of the other uses. -#define MV64340_I2C_SOFT_RESET 0xc01c +#define MV64XXX_I2C_CTLR_NAME "mv64xxx i2c" +#define MV64XXX_I2C_OFFSET 0xc000 +#define MV64XXX_I2C_REG_BLOCK_SIZE0x0020 You have a tab instead of space before MV64XXX_I2C_CTLR_NAME, it seems. Also, you want to align the numerical values using only tabs, no space. Oops. I'll fix that too and repost later today. Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
Jean Delvare wrote:
+config I2C_MV64XXX
+ tristate "Marvell mv64xxx I2C Controller"
+ depends on I2C && MV64X60
&& EXPERIMENTAL?
Done.
+#define I2C_ALGO_MV64XXX 0x17 /* Marvell mv64xxx i2c ctlr */
0x17 is reserved within the legacy i2c project for an USB algorithm,
and 0x18 for virtual busses. Could you please use 0x19 instead,
so as to avoid future collisions?
Done.
+#define MV64XXX_I2C_CTLR_NAME "mv64xxx i2c"
+#define MV64XXX_I2C_OFFSET 0xc000
+#define MV64XXX_I2C_REG_BLOCK_SIZE0x0020
You have a tab instead of space before MV64XXX_I2C_CTLR_NAME, it seems.
Also, you want to align the numerical values using only tabs, no space.
Actually, I did use tabs but what was already there used spaces. So the
patch won't mess up the alignment, I changed mine to spaces too.
The attached patch is a complete replacement for the one posted earlier.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-01-26 14:49:22 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-01-26 14:49:22 -07:00
@@ -476,4 +476,14 @@
This driver can also be built as a module. If so, the module
will be called i2c-pca-isa.
+config I2C_MV64XXX
+ tristate "Marvell mv64xxx I2C Controller"
+ depends on I2C && MV64X60 && EXPERIMENTAL
+ help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mv64xxx.
+
endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile 2005-01-26 14:49:22 -07:00
+++ b/drivers/i2c/busses/Makefile 2005-01-26 14:49:22 -07:00
@@ -20,6 +20,7 @@
obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
obj-$(CONFIG_I2C_KEYWEST) += i2c-keywest.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-01-26 14:49:22 -07:00
@@ -0,0 +1,550 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ *
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "i2c-mv64xxx.h"
+
+/*
+ *
+ *
+ * Finite State Machine & Interrupt Routines
+ *
+ *
+ */
+static inline void
+mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
+{
+ pr_debug("mv64xxx_i2c_fsm: ENTER--state: %d, status: 0x%x\n",
+ drv_data->state, status);
+
+ /*
+* If state is idle, then this is likely the remnants of an old
+* operation that driver has given up on or the user has killed.
+* If so, issue the stop condition and go to idle.
+*/
+ if (drv_data->state == MV64XXX_I2C_STATE_IDLE) {
+ drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
+ drv_data->state = MV64XXX_I2C_STATE_IDLE;
+ pr_debug("mv64xxx_i2c_fsm: EXIT--Entered when in IDLE state\n");
+ return;
+ }
+
+ if (drv_data->state == MV64XXX_I2C_STATE_ABORTING) {
+ drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
+ drv_data->state = MV64XXX_I2C_STATE_IDLE;
+ pr_debug("mv64xxx_i2c_fsm: EXIT--Aborting\n");
+ return;
+ }
+
+ /* The status from the ctlr [mostly] tells us what to do next */
+ switch (status) {
+ /* Start condition interrupt */
+ case MV64XXX_I2C_STATUS_MAST_START: /* 0x08 */
+ case MV64XXX_I2C_STATUS_MAST_REPEAT_START: /* 0x10 */
+ drv_data->action = MV64XXX_I2C_ACTION_SEND_ADDR_1;
+ drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK;
+ break;
+
+ /* Performing a write
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
t;, -rc);
+ dev_err(dev, "mv64xxx: Can't add i2c adapter, rc: %d\n",
+ -rc);
free_irq(drv_data->irq, drv_data);
mv64xxx_i2c_unmap_regs(drv_data);
kfree(drv_data);
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.h b/drivers/i2c/busses/i2c-mv64xxx.h
--- a/drivers/i2c/busses/i2c-mv64xxx.h 2005-01-26 16:52:56 -07:00
+++ /dev/null Wed Dec 31 16:00:00 196900
@@ -1,99 +0,0 @@
-/*
- * drivers/i2c/busses/i2c-mv64xxx.h
- *
- * Driver for the i2c controller on the Marvell line of host bridges for MIPS
- * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
- *
- * Author: Mark A. Greer <[EMAIL PROTECTED]>
- *
- * 2005 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- */
-
-#ifndef I2C_MV64XXX_H
-#define I2C_MV64XXX_H
-
-/* Register defines */
-#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
-#defineMV64XXX_I2C_REG_DATA0x04
-#defineMV64XXX_I2C_REG_CONTROL 0x08
-#defineMV64XXX_I2C_REG_STATUS 0x0c
-#defineMV64XXX_I2C_REG_BAUD0x0c
-#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
-#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
-
-#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
-#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
-#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
-#defineMV64XXX_I2C_REG_CONTROL_START 0x0020
-#defineMV64XXX_I2C_REG_CONTROL_TWSIEN 0x0040
-#defineMV64XXX_I2C_REG_CONTROL_INTEN 0x0080
-
-/* Ctlr status values */
-#defineMV64XXX_I2C_STATUS_BUS_ERR 0x00
-#defineMV64XXX_I2C_STATUS_MAST_START 0x08
-#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
-#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
-#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
-#defineMV64XXX_I2C_STATUS_MAST_WR_ACK 0x28
-#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK 0x30
-#defineMV64XXX_I2C_STATUS_MAST_LOST_ARB0x38
-#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
-#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_NO_ACK 0x48
-#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_ACK 0x50
-#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_NO_ACK 0x58
-#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK 0xd0
-#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK0xd8
-#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_ACK 0xe0
-#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK0xe8
-#defineMV64XXX_I2C_STATUS_NO_STATUS0xf8
-
-/* Driver states */
-enum {
- MV64XXX_I2C_STATE_INVALID,
- MV64XXX_I2C_STATE_IDLE,
- MV64XXX_I2C_STATE_WAITING_FOR_START_COND,
- MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK,
- MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK,
- MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_ACK,
- MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_DATA,
- MV64XXX_I2C_STATE_ABORTING,
-};
-
-/* Driver actions */
-enum {
- MV64XXX_I2C_ACTION_INVALID,
- MV64XXX_I2C_ACTION_CONTINUE,
- MV64XXX_I2C_ACTION_SEND_START,
- MV64XXX_I2C_ACTION_SEND_ADDR_1,
- MV64XXX_I2C_ACTION_SEND_ADDR_2,
- MV64XXX_I2C_ACTION_SEND_DATA,
- MV64XXX_I2C_ACTION_RCV_DATA,
- MV64XXX_I2C_ACTION_RCV_DATA_STOP,
- MV64XXX_I2C_ACTION_SEND_STOP,
-};
-
-struct mv64xxx_i2c_data {
- int irq;
- uintstate;
- uintaction;
- u32 cntl_bits;
- void*reg_base;
- ulong reg_base_p;
- u32 addr1;
- u32 addr2;
- uintbytes_left;
- uintbyte_posn;
- uintblock;
- int rc;
- u32 freq_m;
- u32 freq_n;
- wait_queue_head_t waitq;
- spinlock_t lock;
- struct i2c_msg *msg;
- struct i2c_adapter adapter;
-};
-
-#endif /* I2C_MV64XXX_H */
[PATCH][I2C] Marvell mv64xxx i2c driver
Greg, Philip,
Marvell makes a line of host bridge for PPC and MIPS systems. On those
bridges is an i2c controller. This patch adds the driver for that i2c
controller.
Please let me know if you see any problems with this patch.
Also, if you're not the correct person(s), please point me to who is.
Thanks,
Mark
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-01-25 18:15:24 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-01-25 18:15:24 -07:00
@@ -476,4 +476,14 @@
This driver can also be built as a module. If so, the module
will be called i2c-pca-isa.
+config I2C_MV64XXX
+ tristate "Marvell mv64xxx I2C Controller"
+ depends on I2C && MV64X60
+ help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mv64xxx.
+
endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile 2005-01-25 18:15:24 -07:00
+++ b/drivers/i2c/busses/Makefile 2005-01-25 18:15:24 -07:00
@@ -20,6 +20,7 @@
obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
obj-$(CONFIG_I2C_KEYWEST) += i2c-keywest.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-01-25 18:15:24 -07:00
@@ -0,0 +1,550 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ *
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "i2c-mv64xxx.h"
+
+/*
+ *
+ *
+ * Finite State Machine & Interrupt Routines
+ *
+ *
+ */
+static inline void
+mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
+{
+ pr_debug("mv64xxx_i2c_fsm: ENTER--state: %d, status: 0x%x\n",
+ drv_data->state, status);
+
+ /*
+* If state is idle, then this is likely the remnants of an old
+* operation that driver has given up on or the user has killed.
+* If so, issue the stop condition and go to idle.
+*/
+ if (drv_data->state == MV64XXX_I2C_STATE_IDLE) {
+ drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
+ drv_data->state = MV64XXX_I2C_STATE_IDLE;
+ pr_debug("mv64xxx_i2c_fsm: EXIT--Entered when in IDLE state\n");
+ return;
+ }
+
+ if (drv_data->state == MV64XXX_I2C_STATE_ABORTING) {
+ drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
+ drv_data->state = MV64XXX_I2C_STATE_IDLE;
+ pr_debug("mv64xxx_i2c_fsm: EXIT--Aborting\n");
+ return;
+ }
+
+ /* The status from the ctlr [mostly] tells us what to do next */
+ switch (status) {
+ /* Start condition interrupt */
+ case MV64XXX_I2C_STATUS_MAST_START: /* 0x08 */
+ case MV64XXX_I2C_STATUS_MAST_REPEAT_START: /* 0x10 */
+ drv_data->action = MV64XXX_I2C_ACTION_SEND_ADDR_1;
+ drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK;
+ break;
+
+ /* Performing a write */
+ case MV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK: /* 0x18 */
+ if (drv_data->msg->flags & I2C_M_TEN) {
+ drv_data->action = MV64XXX_I2C_ACTION_SEND_ADDR_2;
+ drv_data->state =
+ MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK;
+ break;
+ }
+ /* FALLTHRU */
+ case MV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK: /* 0xd0 */
+ case MV64XXX_I2C_STATUS_MAST_WR_ACK: /* 0x28 */
+ if (drv_data->bytes_left > 0) {
+ drv_data->action = MV64XXX_I2C_ACTION_SEND_DATA;
+
[PATCH][SERIAL] mpsc updates
Hi again, Andrew.
This patch:
- replaces several macros with the actual code
- change the type of pointer variables from u32 to void *
- removes unecessary casts
- puts the contents of mpsc_defs.h into mpsc.h and removes the mpsc_defs.h
- reflects the new names of some structs
- cleans up some whitespace
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c
--- a/drivers/serial/mpsc.c 2005-01-25 17:28:43 -07:00
+++ b/drivers/serial/mpsc.c 2005-01-25 17:28:43 -07:00
@@ -36,16 +36,14 @@
*
* 1) Some chips have an erratum where several regs cannot be
* read. To work around that, we keep a local copy of those regs in
- * 'mpsc_port_info' and use the *_M or *_S macros when accessing those regs.
+ * 'mpsc_port_info'.
*
* 2) Some chips have an erratum where the ctlr will hang when the SDMA ctlr
- * accesses system mem in a cache coherent region. This *should* be a
- * show-stopper when coherency is turned on but it seems to work okay as
- * long as there are no snoop hits. Therefore, the ring buffer entries and
- * the buffers themselves are allocated via 'dma_alloc_noncoherent()' and
- * 'dma_cache_sync()' is used. Also, since most PPC platforms are coherent
- * which makes 'dma_cache_sync()' a no-op, explicit cache management macros
- * have been added ensuring there are no snoop hits when coherency is on.
+ * accesses system mem with coherency enabled. For that reason, the driver
+ * assumes that coherency for that ctlr has been disabled. This means
+ * that when in a cache coherent system, the driver has to manually manage
+ * the data cache on the areas that it touches because the dma_* macro are
+ * basically no-ops.
*
* 3) There is an erratum (on PPC) where you can't use the instruction to do
* a DMA_TO_DEVICE/cache clean so DMA_BIDIRECTIONAL/flushes are used in places
@@ -54,7 +52,6 @@
* 4) AFAICT, hardware flow control isn't supported by the controller --MAG.
*/
-#include
#include "mpsc.h"
/*
@@ -81,25 +78,48 @@
static void
mpsc_brg_init(struct mpsc_port_info *pi, u32 clk_src)
{
+ u32 v;
+
+ v = (pi->mirror_regs) ? pi->BRG_BCR_m : readl(pi->brg_base + BRG_BCR);
+ v = (v & ~(0xf << 18)) | ((clk_src & 0xf) << 18);
+
if (pi->brg_can_tune)
- MPSC_MOD_FIELD_M(pi, brg, BRG_BCR, 1, 25, 0);
+ v &= ~(1 << 25);
+
+ if (pi->mirror_regs)
+ pi->BRG_BCR_m = v;
+ writel(v, pi->brg_base + BRG_BCR);
- MPSC_MOD_FIELD_M(pi, brg, BRG_BCR, 4, 18, clk_src);
- MPSC_MOD_FIELD(pi, brg, BRG_BTR, 16, 0, 0);
+ writel(readl(pi->brg_base + BRG_BTR) & 0x,
+ pi->brg_base + BRG_BTR);
return;
}
static void
mpsc_brg_enable(struct mpsc_port_info *pi)
{
- MPSC_MOD_FIELD_M(pi, brg, BRG_BCR, 1, 16, 1);
+ u32 v;
+
+ v = (pi->mirror_regs) ? pi->BRG_BCR_m : readl(pi->brg_base + BRG_BCR);
+ v |= (1 << 16);
+
+ if (pi->mirror_regs)
+ pi->BRG_BCR_m = v;
+ writel(v, pi->brg_base + BRG_BCR);
return;
}
static void
mpsc_brg_disable(struct mpsc_port_info *pi)
{
- MPSC_MOD_FIELD_M(pi, brg, BRG_BCR, 1, 16, 0);
+ u32 v;
+
+ v = (pi->mirror_regs) ? pi->BRG_BCR_m : readl(pi->brg_base + BRG_BCR);
+ v &= ~(1 << 16);
+
+ if (pi->mirror_regs)
+ pi->BRG_BCR_m = v;
+ writel(v, pi->brg_base + BRG_BCR);
return;
}
@@ -115,10 +135,16 @@
* that accounts for the way the mpsc is set up is:
* CDV = (clk / (baud*2*16)) - 1 ==> CDV = (clk / (baud << 5)) - 1.
*/
- u32 cdv = (pi->port.uartclk / (baud << 5)) - 1;
+ u32 cdv = (pi->port.uartclk / (baud << 5)) - 1;
+ u32 v;
mpsc_brg_disable(pi);
- MPSC_MOD_FIELD_M(pi, brg, BRG_BCR, 16, 0, cdv);
+ v = (pi->mirror_regs) ? pi->BRG_BCR_m : readl(pi->brg_base + BRG_BCR);
+ v = (v & 0x) | (cdv & 0x);
+
+ if (pi->mirror_regs)
+ pi->BRG_BCR_m = v;
+ writel(v, pi->brg_base + BRG_BCR);
mpsc_brg_enable(pi);
return;
@@ -135,7 +161,7 @@
static void
mpsc_sdma_burstsize(struct mpsc_port_info *pi, u32 burst_size)
{
- u32 v;
+ u32 v;
pr_debug("mpsc_sdma_burstsize[%d]: burst_size: %d\n",
pi->port.line, burst_size);
@@ -151,7 +177,8 @@
else
v = 0x3;/* 8 64-bit words */
- MPSC_MOD_FIELD(pi, sdma, SDMA_SDC, 2, 12, v);
+ writel((readl(pi->sdma_base + SDMA_SDC) & (0x3 << 12)) | (v << 12),
+ pi->sdma_base + SDMA_SDC);
return;
}
@@ -161,7 +188,8 @@
pr_debug("
