Fix section mismatch by annotating using variable name suffix.
Signed-off-by: NNikanth Karthikesan <knikanth@suse.de>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

drivers/gpio/cs5535-gpio.c: In function 'cs5535_gpio_probe':
drivers/gpio/cs5535-gpio.c:269: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'resource_size_t'
drivers/gpio/cs5535-gpio.c:269: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'resource_size_t'

Use vsprintf extension %pR to format resource.
Original-patch-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This adds MODULE_ALIAS entries to the various cs5535 subdevice modules; this
allows the modules to automatically be loaded when cs5535-mfd loads.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The cs5535-mfd driver now takes care of the PCI BAR handling; this
simplifies the gpio driver a lot.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This adds (well, re-adds actually) handling for events/IRQs through cs5535
GPIOs.  In the wild and wooly world of CS5535, setup_event() is for
assigning an IRQ to a GPIO filter/event pair, and set_irq() sets up the
pair to trigger IRQs.

These should really only be used in highly platform-specific drivers (such
as OLPC's DCON driver).  Sadly, because set_irq() uses MSRs, this causes
the driver to become X86-specific.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The default for non-READ_BACK GPIO regs is to have the clear bits set;
this means that our original errata fix was too simplistic.  This
changes it to the following behavior:

 - when setting GPIOs, ignore the higher order bits (they're for
   clearing, we don't need to care about them).

 - when clearing GPIOs, keep all the bits, but unset (via XOR) the
   lower order bit that negates the clear bit that we care about.  That
   is, if we're clearing GPIO 26 (val = 0x04000000), we first XOR what's
   currently in the register with 0x0400 (GPIO 26's SET bit), and then
   OR that with the GPIO 26's CLEAR bit.
Tested-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The edge detect status GPIOs function differently from the other atomic
model CS5536 GPIO registers; writing 1 to the high bits clears the GPIO,
but writing 1 to the lower bits also clears the bit.

This means that read-modify-write doesn't actually work for it, so don't
apply the errata here.  If a negative edge status gets lost after
resume..  well, we tried our best!
Tested-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The AMD Geode CS5536 Companion Device Silicon Revision B1 Specification
Update mentions the follow as issue #36:

 "Atomic write transactions to the atomic GPIO High Bank Feature Bit
  registers should only affect the bits selected [...]"

 "after Suspend, an atomic write transaction [...] will clear all
  non-selected bits of the accessed register."

In other words, writing to the high bank for a single GPIO bit will
clear every other GPIO bit (but only sometimes after a suspend).

The workaround described is obvious and simple; do a read-modify-write.
This patch does that, and documents why we're doing it.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

My Collabora address is no longer enabled - update the MODULE_AUTHOR
fields of drivers to my current email address.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

gpiolib doesn't need to modify the names and I assume most initializers
use string constants that shouldn't be modified anyhow.

[akpm@linux-foundation.org: fix drivers/gpio/cs5535-gpio.c]
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Kevin Wells <kevin.wells@nxp.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The cs5535-gpio driver's get() function was returning the output value.
This means that the GPIO pins would never work as an input, even if
configured as an input.

The driver should return the READ_BACK value, which is the sensed line
value.  To make that work when the direction is 'output', INPUT_ENABLE
needs to be set.

In addition, the driver was not disabling OUTPUT_ENABLE when the direction
is set to 'input'.  That would cause the GPIO to continue to drive the pin
if the direction was ever set to output.

This issue was noticed when attempting to use the gpiolib driver to read
an external input.  I had previously been using the char/cs5535-gpio
driver.
Signed-off-by: NBen Gardner <gardner.ben@gmail.com>
Acked-by: NAndres Salomon <dilinger@collabora.co.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: <stable@kernel.org>		[2.6.33.x]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Changed number of gpio pins to 32 (according to datasheet)

Added mask to disable some pins

Added gpio_request for checking mask and disabling special pin functions

Added pin names

[dilinger@collabora.co.uk: make printk usage consistent]
Signed-off-by: NTobias Mueller <Tobias_Mueller@twam.info>
Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This creates a CS5535/CS5536 GPIO driver which uses a gpio_chip backend
(allowing GPIO users to use the generic GPIO API if desired) while also
allowing architecture-specific users directly (via the cs5535_gpio_*
functions).

Tested on an OLPC machine.  Some Leemotes also use CS5536 (with a mips
cpu), which is why this is in drivers/gpio rather than arch/x86.
Currently, it conflicts with older geode GPIO support; once MFGPT support
is reworked to also be more generic, the older geode code will be removed.
Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
Cc: David Brownell <david-b@pacbell.net>
Reviewed-by: NAlessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>