[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1421704310-26857-1-git-send-email-rjui@broadcom.com>
Date: Mon, 19 Jan 2015 13:51:47 -0800
From: Ray Jui <rjui@...adcom.com>
To: Wolfram Sang <wsa@...-dreams.de>,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>,
Arend van Spriel <arend@...adcom.com>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
"Mark Rutland" <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Grant Likely <grant.likely@...aro.org>,
Christian Daudt <bcm@...thebug.org>,
Matt Porter <mporter@...aro.org>,
Florian Fainelli <f.fainelli@...il.com>,
Russell King <linux@....linux.org.uk>
CC: Scott Branden <sbranden@...adcom.com>, <linux-i2c@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<bcm-kernel-feedback-list@...adcom.com>,
<devicetree@...r.kernel.org>, "Ray Jui" <rjui@...adcom.com>
Subject: [PATCH v7 0/3] Add I2C support to Broadcom iProc
This patchset contains the initial I2C support for Broadcom iProc family of
SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has a
size of 64 bytes. The iProc I2C controller supports two bus speeds including
standard mode (100 kHz) and fast mode (400 kHz)
Changes from v6:
- Get rid of unnecessary atomic variable usage in the driver
- Improve the "waiting for transaction to complete" logic further by making
sure there's no pending/ongoing interrupt by the time when flag
'xfer_is_done' is checked
- After disabling interrupt with 'writel', add 'readl' to the same register
to flush the bus to ensure the write has gone through
Changes from v5:
- Improve the "waiting for transaction to be complete" logic to take care of
the corner case when an interrupt fires after wait_for_completion_timeout
times out
- Improve the logic to disable I2C interrupt in the remove function. Make it
more generic so it works for both dedicated and shared interrupt
Changes from v4:
- Remove redundant header file includes
- Change the logic that waits for the host controller to be idle to
simply return -EBUSY
- Use proper print level and error codes in the driver
- Allow zero length message in the driver to support I2C_SMBUS_QUICK
- Change back to use devm_request_irq. Disable interrupt in the remove
function so there's no outstanding I2C interrupt when the driver is
being removed from the framework
- Other minor miscellaneous improvements and fixes
Changes from v3:
- Add config dependency to COMPILE_TEST to allow the driver to be build tested
by other platforms
- Improve CPU utilization efficiency in the loop of waiting for bus to idle
- Add more comment in the driver to clarify the way how the "start busy"
interrupt is triggered from the I2C controller
- Fix inconsistent coding style and format
- Improve the bus speed validation logic in the driver
- Add code to free the interrupt line in driver's remove function. Also
change to use non-devm API to request the interrupt line
- Other miscellaneous improvements and fixes
Changes from v2:
- Have the I2C driver default to y so it does not need to be selected from
ARCH_BCM_IPROC. This also helps to get rid of one patch. The driver still
depends on ARCH_BCM_IPROC
- Get rid of redundant check on resource returned by platform_get_resource
Changes from v1:
- Fix function argument parenthesis
- Get rid of redundant driver owner field
Ray Jui (3):
i2c: iProc: define Broadcom iProc I2C binding
i2c: iproc: Add Broadcom iProc I2C Driver
ARM: dts: add I2C device nodes for Broadcom Cygnus
.../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 37 ++
arch/arm/boot/dts/bcm-cygnus.dtsi | 20 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-bcm-iproc.c | 505 ++++++++++++++++++++
5 files changed, 573 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists