aboutsummaryrefslogtreecommitdiff
path: root/drivers/i2c/Makefile
AgeCommit message (Collapse)Author
2014-08-19i2c: rework kernel config I2C_ACPILan Tianyu
Commit da3c6647(I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI config) adds a new kernel config I2C_ACPI and make I2C core built in when the config is selected. This is wrong because distributions etc generally compile I2C as a module and the commit broken that. This patch is to rename I2C_ACPI to ACPI_I2C_OPREGION. New config only controls ACPI I2C operation region code and depends on I2C=y. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> [wsa: removed unrelated change for Kconfig] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-06-27I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI configLan Tianyu
Clean up ACPI related code in the i2c core and add CONFIG_I2C_ACPI to enable I2C ACPI code. Current there is a race between removing I2C ACPI operation region and ACPI AML code accessing. So make i2c core built-in if CONFIG_I2C_ACPI is set. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-06-27I2C/ACPI: Add i2c ACPI operation region supportLan Tianyu
ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation region. It allows ACPI aml code able to access such kind of devices to implement some ACPI standard method. ACPI Spec defines some access attribute to associate with i2c protocol. AttribQuick Read/Write Quick Protocol AttribSendReceive Send/Receive Byte Protocol AttribByte Read/Write Byte Protocol AttribWord Read/Write Word Protocol AttribBlock Read/Write Block Protocol AttribBytes Read/Write N-Bytes Protocol AttribProcessCall Process Call Protocol AttribBlockProcessCall Write Block-Read Block Process Call Protocol AttribRawBytes Raw Read/Write N-BytesProtocol AttribRawProcessBytes Raw Process Call Protocol On the Asus T100TA, Bios use GenericSerialBus operation region to access i2c device to get battery info. Sample code From Asus T100TA Scope (_SB.I2C1) { Name (UMPC, ResourceTemplate () { I2cSerialBus (0x0066, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C1", 0x00, ResourceConsumer, , ) }) ... OperationRegion (DVUM, GenericSerialBus, Zero, 0x0100) Field (DVUM, BufferAcc, NoLock, Preserve) { Connection (UMPC), Offset (0x81), AccessAs (BufferAcc, AttribBytes (0x3E)), FGC0, 8 } ... } Device (BATC) { Name (_HID, EisaId ("PNP0C0A")) // _HID: Hardware ID Name (_UID, One) // _UID: Unique ID ... Method (_BST, 0, NotSerialized) // _BST: Battery Status { If (LEqual (AVBL, One)) { Store (FGC0, BFFG) If (LNotEqual (STAT, One)) { ShiftRight (CHST, 0x04, Local0) And (Local0, 0x03, Local0) If (LOr (LEqual (Local0, One), LEqual (Local0, 0x02))) { Store (0x02, Local1) } ... } The i2c operation region is defined under I2C1 scope. _BST method under battery device BATC read battery status from the field "FCG0". The request would be sent to i2c operation region handler. This patch is to add i2c ACPI operation region support. Due to there are only "Byte" and "Bytes" protocol access on the Asus T100TA, other protocols have not been tested. About RawBytes and RawProcessBytes protocol, they needs specific drivers to interpret reference data from AML code according ACPI 5.0 SPEC(5.5.2.4.5.3.9 and 5.5.2.4.5.3.10). So far, not found such case and will add when find real case. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2012-10-28i2c-stub: Move to drivers/i2cJean Delvare
Move the i2c-stub driver to drivers/i2c, to match the Kconfig entry. This is less confusing that way. I also fixed all checkpatch warnings and errors. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Peter Huewe <peterhuewe@gmx.de>
2011-03-20i2c: Deprecate i2c_driver.attach_adapter and .detach_adapterJean Delvare
The last legitimate user of i2c_driver.attach_adapter and .detach_adapter is gone, so we can finally deprecate these callbacks. The last few drivers which still use these will have to be updated to make use of standard I2C device instantiation ways instead. Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-10-24i2c: Change to new flag variablematt mooney
Replace EXTRA_CFLAGS with ccflags-y. Signed-off-by: matt mooney <mfm@muteddisk.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-08-11i2c: I2C bus multiplexer driver pca954xMichael Lawnick
I2C driver for PCA954x I2C multiplexer series. Signed-off-by: Michael Lawnick <ml.lawnick@gmx.de> Acked-by: Rodolfo Giometti <giometti@linux.it> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-08-11i2c: Multiplexed I2C bus core supportMichael Lawnick
Add multiplexed bus core support. I2C multiplexer and switches like pca954x get instantiated as new adapters per port. Signed-off-by: Michael Lawnick <ml.lawnick@gmx.de> Acked-by: Rodolfo Giometti <giometti@linux.it> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-03-13tsl2550: Move from i2c/chips to miscJean Delvare
Move the last remaining driver from i2c/chips to misc. Good ridance! Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
2010-03-02i2c: Separate Kconfig option for i2c-smbusJean Delvare
Having a separate Kconfig option for i2c-smbus makes it possible to build that support as a module even when i2c-core itself is built-in. Bus drivers which implement SMBus alert should select this option, so in most cases this option is hidden and the user doesn't have to care about it. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Trent Piepho <tpiepho@freescale.com>
2010-03-02i2c: Add SMBus alert supportJean Delvare
SMBus alert support. The SMBus alert protocol allows several SMBus slave devices to share a single interrupt pin on the SMBus master, while still allowing the master to know which slave triggered the interrupt. This is based on preliminary work by David Brownell. The key difference between David's implementation and mine is that his was part of i2c-core, while mine is split into a separate, standalone module named i2c-smbus. The i2c-smbus module is meant to include support for all SMBus extensions to the I2C protocol in the future. The benefit of this approach is a zero cost for I2C bus segments which do not need SMBus alert support. Where David's implementation increased the size of struct i2c_adapter by 7% (40 bytes on i386), mine doesn't touch it. Where David's implementation added over 150 lines of code to i2c-core (+10%), mine doesn't touch it. The only change that touches all the users of the i2c subsystem is a new callback in struct i2c_driver (common to both implementations.) I seem to remember Trent was worried about the footprint of David'd implementation, hopefully mine addresses the issue. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Trent Piepho <tpiepho@freescale.com>
2007-05-01i2c: Add i2c_board_info and i2c_new_device()David Brownell
This provides partial support for new-style I2C driver binding. It builds on "struct i2c_board_info" declarations that identify I2C devices on a given board. This is needed on systems with I2C devices that can't be fully probed and/or autoconfigured, such as many embedded Linux configurations where the way a given I2C device is wired may affect how it must be used. There are two models for declaring such devices: * LATE -- using a public function i2c_new_device(). This lets modules declare I2C devices found *AFTER* a given I2C adapter becomes available. For example, a PCI card could create adapters giving access to utility chips on that card, and this would be used to associate those chips with those adapters. * EARLY -- from arch_initcall() level code, using a non-exported function i2c_register_board_info(). This copies the declarations *BEFORE* such an i2c_adapter becomes available, arranging that i2c_new_device() will be called later when i2c-core registers the relevant i2c_adapter. For example, arch/.../.../board-*.c files would declare the I2C devices along with their platform data, and I2C devices would behave much like PNPACPI devices. (That is, both enumerate from board-specific tables.) To match the exported i2c_new_device(), the previously-private function i2c_unregister_device() is now exported. Pending later patches using these new APIs, this is effectively a NOP. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2005-09-05[PATCH] hwmon: hwmon vs i2c, second round (07/11)Jean Delvare
The only part left in i2c-sensor is the VRM/VRD/VID handling code. This is in no way related to i2c, so it doesn't belong there. Move the code to hwmon, where it belongs. Note that not all hardware monitoring drivers do VRM/VRD/VID operations, so less drivers depend on hwmon-vid than there were depending on i2c-sensor. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05[PATCH] hwmon: hwmon vs i2c, second round (05/11)Jean Delvare
The i2c_detect function has no more user, delete it. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!