Re: [linux-nfc] [PATCH] NFC: trf7970a: Move trf7970a_init inside #ifdef CONFIG_PM_RUNTIME

[Mark A. Greer]

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: [linux-nfc] [PATCH] NFC: trf7970a: Move trf7970a_init inside #ifdef CONFIG_PM_RUNTIME

[Mark A. Greer]

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 ge...@linux-m68k.org
 
 Acked-by: Mark A. Greer mgr...@animalcreek.com

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

[Mark A. Greer]

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: [PATCH] NFC: trf7970a: Move trf7970a_init inside #ifdef CONFIG_PM_RUNTIME

[Mark A. Greer]

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 ge...@linux-m68k.org

Acked-by: Mark A. Greer mgr...@animalcreek.com
--
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 ?

[Mark A. Greer]

[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 ?

[Mark A. Greer]

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 ?

[Mark A. Greer]

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 ?

[Mark A. Greer]

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 ?

[Mark A. Greer]

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 ?

[Mark A. Greer]

[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 ?

[Mark A. Greer]

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/

Re: bq24190: What's the correct API to turn boost mode (OTG) on for the battery charger ?

[Mark A. Greer]

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

[Mark A. Greer]

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=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(5) | \
+BIT(4) | BIT(3) | BIT(2))
+

[PATCH v2] bq24190_charger: Add support for TI BQ24190 Battery Charger

[Mark A. Greer]

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 mgr...@animalcreek.com
---
 - 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-enHQS=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 mgr...@animalcreek.com
+ *
+ * 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 linux/module.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/of_irq.h
+#include linux/of_device.h
+#include linux/pm_runtime.h
+#include linux/power_supply.h
+#include linux/gpio.h
+#include linux/i2c.h
+
+#include linux/power/bq24190_charger.h
+
+
+#defineBQ24190_MANUFACTURERTexas 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

Re: [PATCH] bq24190_charger: Add support for TI BQ24190 Battery Charger

[Mark A. Greer]

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,
> > +   );
> > +   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/

Re: [PATCH] bq24190_charger: Add support for TI BQ24190 Battery Charger

[Mark A. Greer]

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

[Mark A. Greer]

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=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 (BIT(7) | BIT(6) | BIT(5) | \
+

[PATCH] bq24190_charger: Add support for TI BQ24190 Battery Charger

[Mark A. Greer]

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 mgr...@animalcreek.com
---
 - 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-enHQS=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 mgr...@animalcreek.com
+ *
+ * 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 linux/module.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/of_irq.h
+#include linux/of_device.h
+#include linux/pm_runtime.h
+#include linux/power_supply.h
+#include linux/gpio.h
+#include linux/i2c.h
+
+#include linux/power/bq24190_charger.h
+
+
+#defineBQ24190_MANUFACTURERTexas 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

Re: crypto: omap-sham, omap-aes and dma_request_slave_channel_compat()

[Mark A. Greer]

[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: crypto: omap-sham, omap-aes and dma_request_slave_channel_compat()

[Mark A. Greer]

[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

[Mark A. Greer]

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: [PATCH] Don't mark shared helper functions as inline

[Mark A. Greer]

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

[Mark A. Greer]

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, "_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/

Re: [GIT PULL 00/15] arm-soc: changes for v3.6

[Mark A. Greer]

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.

[Mark A. Greer]

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] Serial: MPSC - Set baudrate when BRG divider is set.

[Mark A. Greer]

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

[Mark A. Greer]

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 that.  So the real calcu

[PATCH 3/4] serial: MPSC: Remove duplicate SUPPORT_SYSRQ definition

[Mark A. Greer]

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

[Mark A. Greer]

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(>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

[Mark A. Greer]

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 1/4] serial: MPSC: Remove race between Rx stop restart

[Mark A. Greer]

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 2/4] serial: MPSC: Stop rx engine when CREAD cleared

[Mark A. Greer]

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 3/4] serial: MPSC: Remove duplicate SUPPORT_SYSRQ definition

[Mark A. Greer]

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 asm/io.h
 #include asm/irq.h
 
-#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 4/4] serial: MPSC: Fix coding style and whitespace issues

[Mark A. Greer]

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(123)
 #defineSDMA_DESC_CMDSTAT_O (131)
 
-#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(10)
 #defineSDMA_SDC_SFM(11)
@@ -291,10 +290,10 @@ struct mpsc_port_info *mpsc_device_remove(int index);
 #defineSDMA_1_CAUSE_TXBUF  (110)
 #defineSDMA_1_CAUSE_TXEND  (111)
 
-#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_NAMEMPSC
-#defineMPSC_DEV_NAME   ttyMM
-#defineMPSC_VERSION1.00
+#define MPSC_MAJOR 204
+#define MPSC_MINOR_START   44
+#defineMPSC_DRIVER_NAMEMPSC
+#defineMPSC_DEV_NAME   ttyMM
+#defineMPSC_VERSION1.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 that.  So the real calculation
+ * that accounts for the way the mpsc is set up is:
+ * CDV = (clk / (baud*2*16)) - 1 == CDV = (clk / (baud  5)) - 1.
+ */
+static void mpsc_set_baudrate(struct mpsc_port_info *pi

[PATCH] serial: Clear proper MPSC interrupt cause bits

[Mark A. Greer]

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

[Mark A. Greer]

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/

Re: [PATCH] serial: Clear proper MPSC interrupt cause bits

[Mark A. Greer]

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

[Mark A. Greer]

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/

[PATCH] serial: Clear proper MPSC interrupt cause bits

[Mark A. Greer]

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/

[PATCH] serial: Clear proper MPSC interrupt cause bits

[Mark A. Greer]

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

[Mark A. Greer]

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 1/2] rtc: add rtc-m41txx driver

[Mark A. Greer]

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

[Mark A. Greer]

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  0x28
+#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK  

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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 linux/kernel.h
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/mv643xx.h
+#include asm/io.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
+#define

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

Bartlomiej Zolnierkiewicz wrote:
Hi,
just a minor thing
 

+static int __devinit
+mv64xxx_i2c_init(void)
+{
+   return driver_register(_i2c_driver);
+}
   

__init
 

+static void __devexit
+mv64xxx_i2c_exit(void)
+{
+   driver_unregister(_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_STATUS_NO_STATUS 

[PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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

[PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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 linux/kernel.h
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/mv643xx.h
+#include asm/io.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

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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 linux/kernel.h
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/mv643xx.h
+#include asm/io.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

Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver

[Mark A. Greer]

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(_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 = min;
+   hour

Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver

[Mark A. Greer]

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] ST M41T00 I2C RTC chip driver

[Mark A. Greer]

From http://archives.andrew.net.au/lm-sensors/msg29319.html:
Mark A. Greer wrote:
snip
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] ST M41T00 I2C RTC chip driver

[Mark A. Greer]

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 linux/kernel.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/rtc.h
+#include linux/bcd.h
+
+#include asm/time.h
+#include asm/rtc.h
+
+#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 = min;
+   hour1 = hour;
+   day1 = day;
+   mon1 = mon;
+   year1 = year

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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

[Mark A. Greer]

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) MontaVista, Software, Inc.  This 

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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) 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 linux

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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

[Mark A. Greer]

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
+#defineMV64XXX_I2C_STATUS_MA

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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.
 

snip of xxx_probe modifications

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 linux/kernel.h
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/mv643xx.h
+#include asm/io.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
+#define

Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver

[Mark A. Greer]

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(_driver);
+}
+static void __devexit
+m41t00_exit(void)
+{
+	i2c_del_driver(_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;
+
+   sec = min = hour = day = mon = year = 0;
+   sec1 = m

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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] Marvell mv64xxx i2c driver

[Mark A. Greer]

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 linux/kernel.h
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/mv643xx.h
+#include asm/io.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

Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver

[Mark A. Greer]

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 linux/kernel.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/rtc.h
+#include linux/bcd.h
+
+#include asm/time.h
+#include asm/rtc.h
+
+#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

Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver

[Mark A. Greer]

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

[Mark A. Greer]

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

[Mark A. Greer]

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(_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(_client->dev, "m41t00: can't read rtc chip\n");
+   sec = min = hour = day = mon = year = 0;
+   }
+   up(_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, mon, day, hour, min, sec);
+}
+
+static voi

[PATCH][I2C] ST M41T00 I2C RTC chip driver

[Mark A. Greer]

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 linux/kernel.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/rtc.h
+#include linux/bcd.h
+
+#include asm/time.h
+#include asm/rtc.h
+
+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, mon, day, hour, min, sec);
+}
+
+static void
+m41t00_set_tlet(ulong arg

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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/

Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver

[Mark A. Greer]

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

[Mark A. Greer]

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

[Mark A. Greer]

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

[Mark A. Greer]

t;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 */

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

);
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 */

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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 linux/config.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/init.h
+#include linux/pci.h
+#include linux/wait.h
+#include linux/spinlock.h
+#include asm/io.h
+#include asm/ocp.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/mv643xx.h
+#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

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

Jean Delvare wrote:
Hi Mark,
Thanks for the commenting, Jean.
snip
 

+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/

[PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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

[Mark A. Greer]

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("mpsc_sdma_init[%d]: burst_size: %d\n", pi->port.line

[PATCH][SERIAL] mpsc updates

[Mark A. Greer]

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 linux/mv643xx.h
 #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(mpsc_sdma_init[%d]: burst_size: %d\n, pi-port.line,
burst_size);
 
-   MPSC_MOD_FIELD(pi, sdma, SDMA_SDC, 10, 0, 0x03f);
+   writel((readl(pi-sdma_base + SDMA_SDC)  0x3ff) | 0x03f,
+   pi-sdma_base + SDMA_SDC);
mpsc_sdma_burstsize(pi, burst_size);
return;
 }
@@ -169,16 +197,21

[PATCH][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

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 linux/config.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/init.h
+#include linux/pci.h
+#include linux/wait.h
+#include linux/spinlock.h
+#include asm/io.h
+#include asm/ocp.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/mv643xx.h
+#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