talos-obmc-linux/drivers/i2c, branch dev-5.0

i2c: aspeed: Add multi-master use case support

2019-04-12T01:58:49+00:00

In multi-master environment, this driver's master cannot know exactly when a peer master sends data to this driver's slave so cases can be happened that this master tries sending data through the master_xfer function but slave data from a peer master is still being processed or slave xfer is started by a peer immediately after it queues a master command. To support multi-master use cases properly, this H/W provides arbitration in physical level and it provides priority based command handling too to avoid conflicts in multi-master environment, means that if a master and a slave events happen at the same time, H/W will handle a higher priority event first and a pending event will be handled when bus comes back to the idle state. To support this H/W feature properly, this patch adds the 'pending' state of master and its handling code so that the pending master xfer can be continued after slave operation properly. Signed-off-by: Jae Hyun Yoo Reviewed-by: Brendan Higgins Signed-off-by: Wolfram Sang (cherry picked from commit 2e57b7cebb988a27cee44626ae91424e73823bfb) Signed-off-by: Joel Stanley

i2c: aspeed: Remove hard-coded bus timeout value setting

2019-04-12T01:58:45+00:00

This commit removes hard-coded bus timeout value setting so that it can be set by i2c-core-base. Signed-off-by: Jae Hyun Yoo Reviewed-by: Joel Stanley Reviewed-by: Brendan Higgins Signed-off-by: Wolfram Sang (cherry picked from commit 44783efdfed190088066d4c3470766c28da38a21) Signed-off-by: Joel Stanley

Merge tag 'v5.0.7' into dev-5.0

2019-04-08T03:05:05+00:00

This is the 5.0.7 stable release Signed-off-by: Joel Stanley

i2c: of: Try to find an I2C adapter matching the parent

2019-04-05T20:34:43+00:00

[ Upstream commit e814e688413aabd7b0d75e2a8ed1caa472951dec ] If an I2C adapter doesn't match the provided device tree node, also try matching the parent's device tree node. This allows finding an adapter based on the device node of the parent device that was used to register it. This fixes a regression on Tegra124-based Chromebooks (Nyan) where the eDP controller registers an I2C adapter that is used to read to EDID. After commit 993a815dcbb2 ("dt-bindings: panel: Add missing .txt suffix") this stopped working because the I2C adapter could no longer be found. The approach in this patch fixes the regression without introducing the issues that the above commit solved. Fixes: 17ab7806de0c ("drm: don't link DP aux i2c adapter to the hardware device node") Signed-off-by: Thierry Reding Tested-by: Tristan Bastian Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: designware: Do not allow i2c_dw_xfer() calls while suspended

2019-04-05T20:34:32+00:00

[ Upstream commit 2751541555382dfa7661bcfaac3ee0fac49f505d ] On most Intel Bay- and Cherry-Trail systems the PMIC is connected over I2C and the PMIC is accessed through various means by the _PS0 and _PS3 ACPI methods (power on / off methods) of various devices. This leads to suspend/resume ordering problems where a device may be resumed and get its _PS0 method executed before the I2C controller is resumed. On Cherry Trail this leads to errors like these: i2c_designware 808622C1:06: controller timed out ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR video LNXVIDEO:00: Failed to change power state to D0 But on Bay Trail this caused I2C reads to seem to succeed, but they end up returning wrong data, which ends up getting written back by the typical read-modify-write cycle done to turn on various power-resources. Debugging the problems caused by this silent data corruption is quite nasty. This commit adds a check which disallows i2c_dw_xfer() calls to happen until the controller's resume method has completed. Which turns the silent data corruption into getting these errors in dmesg instead: i2c_designware 80860F41:04: Error i2c_dw_xfer call while suspended ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] ACPI Error: Method parse/execution failed \_SB.PCI0.GFX0._PS0, AE_ERROR Which is much better. Note the above errors are an example of issues which this patch will help to debug, the actual fix requires fixing the suspend order and this has been fixed by a different commit. Note the setting / clearing of the suspended flag in the suspend / resume methods is NOT protected by i2c_lock_bus(). This is intentional as these methods get called from i2c_dw_xfer() (through pm_runtime_get/put) a nd i2c_dw_xfer() is called with the i2c_bus_lock held, so otherwise we would deadlock. This means that there is a theoretical race between a non runtime suspend and the suspended check in i2c_dw_xfer(), this is not a problem since normally we should not hit the race and this check is primarily a debugging tool so hitting the check if there are suspend/resume ordering problems does not need to be 100% reliable. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: Allow recovery of the initial IRQ by an I2C client device.

2019-04-05T20:34:31+00:00

[ Upstream commit 93b6604c5a669d84e45fe5129294875bf82eb1ff ] A previous change allowed I2C client devices to discover new IRQs upon reprobe by clearing the IRQ in i2c_device_remove. However, if an IRQ was assigned in i2c_new_device, that information is lost. For example, the touchscreen and trackpad devices on a Dell Inspiron laptop are I2C devices whose IRQs are defined by ACPI extended IRQ types. The client device structures are initialized during an ACPI walk. After removing the i2c_hid device, modprobe fails. This change caches the initial IRQ value in i2c_new_device and then resets the client device IRQ to the initial value in i2c_device_remove. Fixes: 6f108dd70d30 ("i2c: Clear client->irq in i2c_device_remove") Signed-off-by: Jim Broadus Reviewed-by: Benjamin Tissoires Reviewed-by: Charles Keepax [wsa: this is an easy to backport fix for the regression. We will refactor the code to handle irq assignments better in general.] Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

Merge tag 'v5.0.4' into dev-5.0

2019-03-24T23:49:05+00:00

This is the 5.0.4 stable release Signed-off-by: Joel Stanley

i2c: tegra: update maximum transfer size

2019-03-23T19:11:25+00:00

commit b03ff2a23359d0dd6f0a1516c6a9e9c4760ed230 upstream. Tegra194 supports maximum 64K bytes per packet including 12 bytes of packet header irrespective of PIO or DMA mode transfer. This patch updates Tegra194 max write length to account for packet header size for transfers. Cc: stable@vger.kernel.org # 4.20+ Reviewed-by: Dmitry Osipenko Signed-off-by: Sowjanya Komatineni Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: tegra: fix maximum transfer size

2019-03-23T19:11:25+00:00

commit f4e3f4ae1d9c9330de355f432b69952e8cef650c upstream. Tegra186 and prior supports maximum 4K bytes per packet transfer including 12 bytes of packet header. This patch fixes max write length limit to account packet header size for transfers. Cc: stable@vger.kernel.org # 4.4+ Reviewed-by: Dmitry Osipenko Signed-off-by: Sowjanya Komatineni Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: npcm: driver for Poleg i2c controller

2019-03-20T04:43:34+00:00

OpenBMC-Staging-Count: 2 Signed-off-by: Tali Perry Signed-off-by: Tomer Maimon [joel: select CRC8 to fix build error] Signed-off-by: Joel Stanley