- 04 5月, 2019 1 次提交
-
-
由 Jarkko Nikula 提交于
[ Upstream commit 5cd1c56c42beb6d228cc8d4373fdc5f5ec78a5ad ] Add PCI ID for Intel Comet Lake PCH. Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
- 06 4月, 2019 1 次提交
-
-
由 Thierry Reding 提交于
[ 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: 17ab7806 ("drm: don't link DP aux i2c adapter to the hardware device node") Signed-off-by: NThierry Reding <treding@nvidia.com> Tested-by: NTristan Bastian <tristan-c.bastian@gmx.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 24 3月, 2019 3 次提交
-
-
由 Sowjanya Komatineni 提交于
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: NDmitry Osipenko <digetx@gmail.com> Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Paul Kocialkowski 提交于
[ Upstream commit f275a4659484716259cc46268d9043424e51cf0f ] The driver's interrupt handler checks whether a message is currently being handled with the curr_msg pointer. When it is NULL, the interrupt is considered to be unexpected. Similarly, the i2c_start_transfer routine checks for the remaining number of messages to handle in num_msgs. However, these values are never cleared and always keep the message and number relevant to the latest transfer (which might be done already and the underlying message memory might have been freed). When an unexpected interrupt hits with the DONE bit set, the isr will then try to access the flags field of the curr_msg structure, leading to a fatal page fault. The msg_buf and msg_buf_remaining fields are also never cleared at the end of the transfer, which can lead to similar pitfalls. Fix these issues by introducing a cleanup function and always calling it after a transfer is finished. Fixes: e2474541 ("i2c: bcm2835: Fix hang for writing messages larger than 16 bytes") Signed-off-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com> Acked-by: NStefan Wahren <stefan.wahren@i2se.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Shubhrajyoti Datta 提交于
[ Upstream commit d358def706880defa4c9e87381c5bf086a97d5f9 ] In case the hold bit is not needed we are carrying the old values. Fix the same by resetting the bit when not needed. Fixes the sporadic i2c bus lockups on National Instruments Zynq-based devices. Fixes: df8eb569 ("i2c: Add driver for Cadence I2C controller") Reported-by: NKyle Roeschley <kyle.roeschley@ni.com> Acked-by: NMichal Simek <michal.simek@xilinx.com> Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Tested-by: NKyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 14 3月, 2019 1 次提交
-
-
由 Tony Lindgren 提交于
[ Upstream commit c6e2bd956936d925748581e4d0294f10f1d92f2c ] We currently get the following error with pixcir_ts driver during a suspend resume cycle: omap_i2c 4802a000.i2c: controller timed out pixcir_ts 1-005c: pixcir_int_enable: can't read reg 0x34 : -110 pixcir_ts 1-005c: Failed to disable interrupt generation: -110 pixcir_ts 1-005c: Failed to stop dpm_run_callback(): pixcir_i2c_ts_resume+0x0/0x98 [pixcir_i2c_ts] returns -110 PM: Device 1-005c failed to resume: error -110 And at least am437x based devices with pixcir_ts will fail to resume to a touchscreen that is configured as the wakeup-source in device tree for these devices. This is because pixcir_ts tries to reconfigure it's registers for noirq suspend which fails. This also leaves i2c-omap in enabled state for suspend. Let's fix the pixcir_ts issue and make sure i2c-omap is suspended by adding SET_NOIRQ_SYSTEM_SLEEP_PM_OPS. Let's also get rid of some ifdefs while at it and replace them with __maybe_unused as SET_RUNTIME_PM_OPS and SET_NOIRQ_SYSTEM_SLEEP_PM_OPS already deal with the various PM Kconfig options. Reported-by: NKeerthy <j-keerthy@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com> Acked-by: NVignesh R <vigneshr@ti.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 13 2月, 2019 3 次提交
-
-
由 Fabrizio Castro 提交于
[ Upstream commit 51243b73455f2d12cb82abffa7bc9028aec656e0 ] Similarly to R-Car E3, RZ/G2E doesn't come with automatic transmission registers, as such it is not considered compatible with the existing fallback bindings. Add SoC specific binding compatibility to allow for later support for automatic transmission. Signed-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
[ Upstream commit 4f5c85fe3a60ace555d09898166af372547f97fc ] It was observed that when using seqentional mode contrary to the documentation, the SS bit (which is supposed to only be set if automatic/sequence command completed normally), is sometimes set together with NA (NAK in address phase) causing transfer to falsely be considered successful. My assumption is that this does not happen during manual mode since the controller is stopping its work the moment it sets NA/ND bit in status register. This is not the case in Automatic/Sequentional mode where it is still working to send STOP condition and the actual status we get depends on the time when the ISR is run. This patch changes the order of checking status bits in ISR - error conditions are checked first and only if none of them occurred, the transfer may be considered successful. This is required to introduce using of sequentional mode in next patch. Signed-off-by: NKrzysztof Adamski <krzysztof.adamski@nokia.com> Reviewed-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Simon Horman 提交于
[ Upstream commit 5eb316e636eb298c204f5b368526d4480b63c0ba ] Add support for the IIC code for the r8a77990 (R-Car E3). It is not considered compatible with existing fallback bindings due to the documented absence of automatic transmission registers. These registers are currently not used by the driver and thus the provides the same behaviour for "renesas,iic-r8a77990" and "renesas,rcar-gen3-iic". The point of declaring incompatibility is to allow for automatic transmission register support to be added to "renesas,iic-r8a77990" and "renesas,rcar-gen3-iic" in future. Signed-off-by: NSimon Horman <horms+renesas@verge.net.au> Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 17 1月, 2019 1 次提交
-
-
由 Yi Zeng 提交于
commit 6ebec961d59bccf65d08b13fc1ad4e6272a89338 upstream. If adapter->retries is set to a minus value from user space via ioctl, it will make __i2c_transfer and __i2c_smbus_xfer skip the calling to adapter->algo->master_xfer and adapter->algo->smbus_xfer that is registered by the underlying bus drivers, and return value 0 to all the callers. The bus driver will never be accessed anymore by all users, besides, the users may still get successful return value without any error or information log print out. If adapter->timeout is set to minus value from user space via ioctl, it will make the retrying loop in __i2c_transfer and __i2c_smbus_xfer always break after the the first try, due to the time_after always returns true. Signed-off-by: NYi Zeng <yizeng@asrmicro.com> [wsa: minor grammar updates to commit message] Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 12月, 2018 5 次提交
-
-
由 Masahiro Yamada 提交于
[ Upstream commit ece27a337d42a3197935711997f2880f0957ed7e ] Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode, tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us. tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode: Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us Fast-mode: tLOW = 1.39 us, tHIGH = 1.11 us Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Masahiro Yamada 提交于
[ Upstream commit 8469636ab5d8c77645b953746c10fda6983a8830 ] Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode, tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us. tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode: Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us Fast-mode: tLOW = 1.39 us, tHIGH = 1.11 us Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Hans de Goede 提交于
[ Upstream commit 0544ee4b1ad574aec3b6379af5f5cdee42840971 ] Some AMD based HP laptops have a SMB0001 ACPI device node which does not define any methods. This leads to the following error in dmesg: [ 5.222731] cmi: probe of SMB0001:00 failed with error -5 This commit makes acpi_smbus_cmi_add() return -ENODEV instead in this case silencing the error. In case of a failure of the i2c_add_adapter() call this commit now propagates the error from that call instead of -EIO. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
[ Upstream commit 6c7f25cae54b840302e4f1b371dbf318fbf09ab2 ] According to Intel (R) Axxia TM Lionfish Communication Processor Peripheral Subsystem Hardware Reference Manual, the AXXIA I2C module have a programmable Master Wait Timer, which among others, checks the time between commands send in manual mode. When a timeout (25ms) passes, TSS bit is set in Master Interrupt Status register and a Stop command is issued by the hardware. The axxia_i2c_xfer(), does not properly handle this situation, however. For each message a separate axxia_i2c_xfer_msg() is called and this function incorrectly assumes that any interrupt might happen only when waiting for completion. This is mostly correct but there is one exception - a master timeout can trigger if enough time has passed between individual transfers. It will, by definition, happen between transfers when the interrupts are disabled by the code. If that happens, the hardware issues Stop command. The interrupt indicating timeout will not be triggered as soon as we enable them since the Master Interrupt Status is cleared when master mode is entered again (which happens before enabling irqs) meaning this error is lost and the transfer is continued even though the Stop was issued on the bus. The subsequent operations completes without error but a bogus value (0xFF in case of read) is read as the client device is confused because aborted transfer. No error is returned from master_xfer() making caller believe that a valid value was read. To fix the problem, the TSS bit (indicating timeout) in Master Interrupt Status register is checked before each transfer. If it is set, there was a timeout before this transfer and (as described above) the hardware already issued Stop command so the transaction should be aborted thus -ETIMEOUT is returned from the master_xfer() callback. In order to be sure no timeout was issued we can't just read the status just before starting new transaction as there will always be a small window of time (few CPU cycles at best) where this might still happen. For this reason we have to temporally disable the timer before checking for TSS bit. Disabling it will, however, clear the TSS bit so in order to preserve that information, we have to read it in ISR so we have to ensure that the TSS interrupt is not masked between transfers of one transaction. There is no need to call bus recovery or controller reinitialization if that happens so it's skipped. Signed-off-by: NKrzysztof Adamski <krzysztof.adamski@nokia.com> Reviewed-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Wolfram Sang 提交于
[ Upstream commit 0b57436f ] We should check the bus state before reinitializing the IP core. Otherwise, the internal bus busy state which also tracks multi-master activity is lost. Credits go to the Renesas BSP team for suggesting this change. Reported-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Fixes: ae481cc1 ("i2c: rcar: fix resume by always initializing registers before transfer") Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 20 12月, 2018 1 次提交
-
-
由 Arnd Bergmann 提交于
Upstream commit 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events properly") reworked the interrupt handling and fixed a warning in the process: drivers/i2c/busses/i2c-aspeed.c: In function 'aspeed_i2c_bus_irq': drivers/i2c/busses/i2c-aspeed.c:567:1: error: label 'out' defined but not used [-Werror=unused-label] The warning is still present in v4.19.8 and can be fixed either by applying that original patch, or by adding a simple #ifdef. Here, I choose the second simpler option as the original patch seems too invasive for a stable backport. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NBrendan Higgins <brendanhiggins@google.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 27 11月, 2018 2 次提交
-
-
由 Stephen Boyd 提交于
[ Upstream commit 848bd3f3de9d44950c00eda6c115e8e9785440da ] We need to enable runtime PM on this i2c controller before populating child devices with i2c_add_adapter(). Otherwise, if a child device uses runtime PM and stays runtime PM enabled we'll get the following warning at boot. Enabling runtime PM for inactive device (a98000.i2c) with active children [...] Call trace: pm_runtime_enable+0xd8/0xf8 geni_i2c_probe+0x440/0x460 platform_drv_probe+0x74/0xc8 [...] Let's move the runtime PM enabling and setup to before we add the adapter, so that this device can respond to runtime PM requests from children. Fixes: 37692de5 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: NStephen Boyd <swboyd@chromium.org> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Vignesh R 提交于
[ Upstream commit 5b277402deac0691226a947df71c581686bd4020 ] Allow I2C_OMAP to be built for K3 platforms. Signed-off-by: NVignesh R <vigneshr@ti.com> Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 20 10月, 2018 1 次提交
-
-
由 Wolfram Sang 提交于
DMA needs to be cleaned up not only on timeout, but on all errors where it has been setup before. Fixes: 73e8b052 ("i2c: rcar: add DMA support") Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 12 10月, 2018 1 次提交
-
-
由 Stephen Boyd 提交于
This function was renamed in commit 82fe39a6 ("i2c: refactor function to release a DMA safe buffer") but this kernel doc wasn't updated to point at the new function. Rename it. Fixes: 82fe39a6 ("i2c: refactor function to release a DMA safe buffer") Signed-off-by: NStephen Boyd <swboyd@chromium.org> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 05 10月, 2018 1 次提交
-
-
由 Jarkko Nikula 提交于
There are platforms which don't provide input clock rate but provide I2C timing parameters. Commit 3bd4f277 ("i2c: designware: Call i2c_dw_clk_rate() only once in i2c_dw_init_master()") causes needless warning during probe on those platforms since i2c_dw_clk_rate(), which causes the warning when input clock is unknown, is called even when there is no need to calculate timing parameters. Fixes: 3bd4f277 ("i2c: designware: Call i2c_dw_clk_rate() only once in i2c_dw_init_master()") Reported-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Cc: <stable@vger.kernel.org> # 4.19 Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 01 10月, 2018 1 次提交
-
-
由 Edgar Cherkasov 提交于
The i2c-scmi driver crashes when the SMBus Write Block transaction is executed: WARNING: CPU: 9 PID: 2194 at mm/page_alloc.c:3931 __alloc_pages_slowpath+0x9db/0xec0 Call Trace: ? get_page_from_freelist+0x49d/0x11f0 ? alloc_pages_current+0x6a/0xe0 ? new_slab+0x499/0x690 __alloc_pages_nodemask+0x265/0x280 alloc_pages_current+0x6a/0xe0 kmalloc_order+0x18/0x40 kmalloc_order_trace+0x24/0xb0 ? acpi_ut_allocate_object_desc_dbg+0x62/0x10c __kmalloc+0x203/0x220 acpi_os_allocate_zeroed+0x34/0x36 acpi_ut_copy_eobject_to_iobject+0x266/0x31e acpi_evaluate_object+0x166/0x3b2 acpi_smbus_cmi_access+0x144/0x530 [i2c_scmi] i2c_smbus_xfer+0xda/0x370 i2cdev_ioctl_smbus+0x1bd/0x270 i2cdev_ioctl+0xaa/0x250 do_vfs_ioctl+0xa4/0x600 SyS_ioctl+0x79/0x90 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 ACPI Error: Evaluating _SBW: 4 (20170831/smbus_cmi-185) This problem occurs because the length of ACPI Buffer object is not defined/initialized in the code before a corresponding ACPI method is called. The obvious patch below fixes this issue. Signed-off-by: NEdgar Cherkasov <echerkasov@dev.rtsoft.ru> Acked-by: NViktor Krasnov <vkrasnov@dev.rtsoft.ru> Acked-by: NMichael Brunner <Michael.Brunner@kontron.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 25 9月, 2018 2 次提交
-
-
由 Colin Ian King 提交于
Trivial fix to spelling mistake in dev_notice message. Signed-off-by: NColin Ian King <colin.king@canonical.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Stephen Boyd 提交于
We shouldn't attempt to DMA map the message buffers passed into this driver from the i2c core unless the message we're mapping have been properly setup for DMA. The i2c core indicates such a situation by setting the I2C_M_DMA_SAFE flag, so check for that flag before using DMA mode. We can also bounce the buffer if it isn't already mapped properly by using the i2c_get_dma_safe_msg_buf() APIs, so do that when we want to use DMA for a message. This fixes a problem where the kernel oopses cleaning pages for a buffer that's mapped into the vmalloc space. The pages are returned from request_firmware() and passed down directly to the i2c master to write to the i2c touchscreen device. Mapping vmalloc buffers with dma_map_single() won't work reliably, causing an oops like below: Unable to handle kernel paging request at virtual address ffffffc01391d000 ... Reported-by: NPhilip Chen <philipchen@chromium.org> Signed-off-by: NStephen Boyd <swboyd@chromium.org> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 07 9月, 2018 1 次提交
-
-
由 Shubhrajyoti Datta 提交于
Disable interrupts while configuring the transfer and enable them back. We have below as the programming sequence 1. start and slave address 2. byte count and stop In some customer platform there was a lot of interrupts between 1 and 2 and after slave address (around 7 clock cyles) if 2 is not executed then the transaction is nacked. To fix this case make the 2 writes atomic. Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Signed-off-by: NMichal Simek <michal.simek@xilinx.com> [wsa: added a newline for better readability] Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
- 05 9月, 2018 1 次提交
-
-
由 Felipe Balbi 提交于
DNV's iTCO is slightly different with SMBCTRL sitting at a different offset when compared to all other devices. Let's fix so that we can properly use iTCO watchdog. Fixes: 84d7f2eb ("i2c: i801: Add support for Intel DNV") Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 03 9月, 2018 3 次提交
-
-
由 Fabio Estevam 提交于
mx8dv never entered into production and there is no other place in the kernel referring to this SoC, so remove it from the driver's compatible entry. Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Masahiro Yamada 提交于
This driver currently emits a STOP if the next message is not I2C_MD_RD. It should not do it because it disturbs the I2C_RDWR ioctl, where read/write transactions are combined without STOP between. Issue STOP only when the message is the last one _or_ flagged with I2C_M_STOP. Fixes: 6a62974b ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Masahiro Yamada 提交于
This driver currently emits a STOP if the next message is not I2C_MD_RD. It should not do it because it disturbs the I2C_RDWR ioctl, where read/write transactions are combined without STOP between. Issue STOP only when the message is the last one _or_ flagged with I2C_M_STOP. Fixes: dd6fd4a3 ("i2c: uniphier: add UniPhier FIFO-less I2C driver") Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 31 8月, 2018 6 次提交
-
-
由 Wolfram Sang 提交于
We only freed the bounce buffer after successful DMA, missing the cases where DMA setup may have gone wrong. Use a better location which always gets called after each message and use 'stop_after_dma' as a flag for a successful transfer. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
After various refactoring over the years, start_ch() doesn't return errno anymore, so make the function return void. This saves the error handling when calling it which in turn eases cleanup of resources of a future patch. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
a) rename to 'put' instead of 'release' to match 'get' when obtaining the buffer b) change the argument order to have the buffer as first argument c) add a new argument telling the function if the message was transferred. This allows the function to be used also in cases where setting up DMA failed, so the buffer needs to be freed without syncing to the message buffer. Also convert the only user. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Jan Kundrát 提交于
Yep, I went looking for one of these, and I wasn't able to find it easily. That's worse than a line which is 82-chars long, IMHO. Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Hans de Goede 提交于
On Bay Trail and Cherry Trail devices we set the pm_disabled flag for I2C busses which the OS shares with the PUNIT as these need special handling. Until now we called dev_pm_syscore_device(dev, true) for I2C controllers with this flag set to keep these I2C controllers always on. After commit 12864ff8 ("ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernation"), this no longer works. This commit modifies lpss_iosf_exit_d3_state() to only run if lpss_iosf_enter_d3_state() has ran before it, so that it does not run on a resume from hibernate (or from S3). On these systems the conditions for lpss_iosf_enter_d3_state() to run never become true, so lpss_iosf_exit_d3_state() never gets called and the 2 LPSS DMA controllers never get forced into D0 mode, instead they are left in their default automatic power-on when needed mode. The not forcing of D0 mode for the DMA controllers enables these systems to properly enter S0ix modes, which is a good thing. But after entering S0ix modes the I2C controller connected to the PMIC no longer works, leading to e.g. broken battery monitoring. The _PS3 method for this I2C controller looks like this: Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 { If ((((PMID == 0x04) || (PMID == 0x05)) || (PMID == 0x06))) { Return (Zero) } PSAT |= 0x03 Local0 = PSAT /* \_SB_.I2C5.PSAT */ } Where PMID = 0x05, so we enter the Return (Zero) path on these systems. So even if we were to not call dev_pm_syscore_device(dev, true) the I2C controller will be left in D0 rather then be switched to D3. Yet on other Bay and Cherry Trail devices S0ix is not entered unless *all* I2C controllers are in D3 mode. This combined with the I2C controller no longer working now that we reach S0ix states on these systems leads to me believing that the PUNIT itself puts the I2C controller in D3 when all other conditions for entering S0ix states are true. Since now the I2C controller is put in D3 over a suspend/resume we must re-initialize it afterwards and that does indeed fix it no longer working. This commit implements this fix by: 1) Making the suspend_late callback a no-op if pm_disabled is set and making the resume_early callback skip the clock re-enable (since it now was not disabled) while still doing the necessary I2C controller re-init. 2) Removing the dev_pm_syscore_device(dev, true) call, so that the suspend and resume callbacks are actually called. Normally this would cause the ACPI pm code to call _PS3 putting the I2C controller in D3, wreaking havoc since it is shared with the PUNIT, but in this special case the _PS3 method is a no-op so we can safely allow a "fake" suspend / resume. Fixes: 12864ff8 ("ACPI / LPSS: Avoid PM quirks on suspend and resume ...") Link: https://bugzilla.kernel.org/show_bug.cgi?id=200861 Cc: 4.15+ <stable@vger.kernel.org> # 4.15+ Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Mika Westerberg 提交于
Commit 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR") made it possible for AML code to access SMBus I/O ports by installing custom SystemIO OpRegion handler and blocking i80i driver access upon first AML read/write to this OpRegion. However, while ThinkPad T560 does have SystemIO OpRegion declared under the SMBus device, it does not access any of the SMBus registers: Device (SMBU) { ... OperationRegion (SMBP, PCI_Config, 0x50, 0x04) Field (SMBP, DWordAcc, NoLock, Preserve) { , 5, TCOB, 11, Offset (0x04) } Name (TCBV, 0x00) Method (TCBS, 0, NotSerialized) { If ((TCBV == 0x00)) { TCBV = (\_SB.PCI0.SMBU.TCOB << 0x05) } Return (TCBV) /* \_SB_.PCI0.SMBU.TCBV */ } OperationRegion (TCBA, SystemIO, TCBS (), 0x10) Field (TCBA, ByteAcc, NoLock, Preserve) { Offset (0x04), , 9, CPSC, 1 } } Problem with the current approach is that it blocks all I/O port access and because this system has touchpad connected to the SMBus controller after first AML access (happens during suspend/resume cycle) the touchpad fails to work anymore. Fix this so that we allow ACPI AML I/O port access if it does not touch the region reserved for the SMBus. Fixes: 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR") Link: https://bugzilla.kernel.org/show_bug.cgi?id=200737Reported-by: NYussuf Khalil <dev@pp3345.net> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 24 8月, 2018 4 次提交
-
-
由 Sedat Dilek 提交于
This can be dropped with commit 771c0353 ("deprecate the '__deprecated' attribute warnings entirely and for good") now in upstream. And we got rid of the last __deprecated use, too. Signed-off-by: NSedat Dilek <sedat.dilek@credativ.de> [wsa: shortened commit message to reflect the current situation] Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NSimon Horman <horms+renesas@verge.net.au> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Peter Korsgaard 提交于
The old @sunsite.dk address is no longer active, so update the references. Signed-off-by: NPeter Korsgaard <peter@korsgaard.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
There aren't any users left. Remove this callback from the 2.4 times. Phew, finally, that took years to reach... Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 20 8月, 2018 1 次提交
-
-
由 Wolfram Sang 提交于
When doing a REP_START after a read message, the driver used to trigger a STOP first which would then be overwritten by REP_START. This was the only stable method found when doing the last refactoring. However, this was not in accordance with the documentation. After research from our BSP team and myself, we now can implement a version which works and is according to the documentation. The new approach ensures the ICMCR register is only changed when really needed. Tested on a R-Car Gen2 (H2) and Gen3 with DMA (M3N). Signed-off-by: NHiromitsu Yamasaki <hiromitsu.yamasaki.ym@renesas.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NUlrich Hecht <uli+renesas@fpond.eu> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-