linux-dev/Documentation/i2c/smbus-protocol, branch master

docs: i2c: convert to ReST and add to driver-api bookset

2019-07-31T19:25:27Z

Convert each file at I2C subsystem, renaming them to .rst and adding to the driver-api book. Signed-off-by: Mauro Carvalho Chehab Acked-by: Wolfram Sang Acked-by: Alexandre Belloni Acked-by: Jonathan Cameron Signed-off-by: Jonathan Corbet

i2c: use an IRQ to report Host Notify events, not alert

2016-11-24T15:22:06Z

The current SMBus Host Notify implementation relies on .alert() to relay its notifications. However, the use cases where SMBus Host Notify is needed currently is to signal data ready on touchpads. This is closer to an IRQ than a custom API through .alert(). Given that the 2 touchpad manufacturers (Synaptics and Elan) that use SMBus Host Notify don't put any data in the SMBus payload, the concept actually matches one to one. Benefits are multiple: - simpler code and API: the client will just have an IRQ, and nothing needs to be added in the adapter beside internally enabling it. - no more specific workqueue, the threading is handled by IRQ core directly (when required) - no more races when removing the device (the drivers are already required to disable irq on remove) - simpler handling for drivers: use plain regular IRQs - no more dependency on i2c-smbus for i2c-i801 (and any other adapter) - the IRQ domain is created automatically when the adapter exports the Host Notify capability - the IRQ are assign only if ACPI, OF and the caller did not assign one already - the domain is automatically destroyed on remove - fewer lines of code (minus 20, yeah!) Signed-off-by: Benjamin Tissoires Signed-off-by: Wolfram Sang

i2c: smbus: add SMBus Host Notify support

2016-06-17T11:24:05Z

SMBus Host Notify allows a slave device to act as a master on a bus to notify the host of an interrupt. On Intel chipsets, the functionality is directly implemented in the firmware. We just need to export a function to call .alert() on the proper device driver. i2c_handle_smbus_host_notify() behaves like i2c_handle_smbus_alert(). When called, it schedules a task that will be able to sleep to go through the list of devices attached to the adapter. The current implementation allows one Host Notification to be scheduled while an other is running. Tested-by: Andrew Duggan Signed-off-by: Benjamin Tissoires Signed-off-by: Wolfram Sang

i2c: core: Remove definition of i2c_smbus_process_call

2013-01-28T04:26:41Z

i2c_smbus_process_call has no users in the kernel, so this can be removed. Documentation for the same has been updated accordingly. Fixes following sparse warning. drivers/i2c/i2c-core.c:1871:5: warning: symbol 'i2c_smbus_process_call' was not declared. Should it be static? [wsa: updated the documentation] Signed-off-by: Tushar Behera Signed-off-by: Wolfram Sang

i2c: Mention functionality flags in SMBus protocol documentation

2012-12-16T20:11:55Z

While the mapping between I2C adapter functionality flags and i2c_smbus_*() helper functions is rather obvious, let's still document it for clarity. Also drop the reference to 2 command byte I2C block reads, there is no support for that in the kernel at the moment. Signed-off-by: Jean Delvare

i2c: Functions for byte-swapped smbus_write/read_word_data

2011-10-30T12:47:25Z

Reimplemented at least 17 times discounting error mangling cases where it could be used. Signed-off-by: Jonathan Cameron Signed-off-by: Jean Delvare

i2c: Add SMBus alert support

2010-03-02T11:23:42Z

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 Acked-by: Jonathan Cameron Cc: David Brownell Cc: Trent Piepho

i2c: Restore i2c_smbus_process_call function

2008-10-14T15:30:06Z

Restore the i2c_smbus_process_call() as one driver (for the Micronas MAP5401) will need it soon. [JD: Update documentation accordingly.] Signed-off-by: Prakash Mortha Signed-off-by: Jean Delvare

i2c: Delete unused function i2c_smbus_write_quick

2008-07-14T20:38:23Z

Function i2c_smbus_write_quick has no users left, so we can delete it. Also update the list of these helper functions which are gone but could be added back if needed. Signed-off-by: Jean Delvare

i2c: Improve smbus-protocol documentation

2008-05-11T18:37:05Z

Improve the smbus-protocol documentation file somewhat: - Use the names of the SMBus protocol operations (from the 2.0 specification), not made-up-for-Linux names. - Add the name of the call used to execute each operation ... and point out that there are mismatches, where functions execute different protocol operations than their names specify. The most confusing examples are that "Read Byte" isn't executed by i2c_smbus_read_byte(), and that "Write Byte" isn't executed by i2c_smbus_write_byte(). When coding, that's not as bad as it may seem; but that case would seem to be worth fixing. Signed-off-by: David Brownell Signed-off-by: Jean Delvare