Skip to content
Snippets Groups Projects
  1. Feb 26, 2020
  2. Sep 13, 2019
  3. Aug 14, 2019
    • Fabio Estevam's avatar
      Revert "i2c: imx: improve the error handling in i2c_imx_dma_request()" · e8c220fa
      Fabio Estevam authored
      
      Since commit e1ab9a46 ("i2c: imx: improve the error handling in
      i2c_imx_dma_request()") when booting with the DMA driver as module (such
      as CONFIG_FSL_EDMA=m) the following endless clk warnings are seen:
      
      [  153.077831] ------------[ cut here ]------------
      [  153.082528] WARNING: CPU: 0 PID: 15 at drivers/clk/clk.c:924 clk_core_disable_lock+0x18/0x24
      [  153.093077] i2c0 already disabled
      [  153.096416] Modules linked in:
      [  153.099521] CPU: 0 PID: 15 Comm: kworker/0:1 Tainted: G        W         5.2.0+ #321
      [  153.107290] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
      [  153.113772] Workqueue: events deferred_probe_work_func
      [  153.118979] [<c0019560>] (unwind_backtrace) from [<c0014734>] (show_stack+0x10/0x14)
      [  153.126778] [<c0014734>] (show_stack) from [<c083f8dc>] (dump_stack+0x9c/0xd4)
      [  153.134051] [<c083f8dc>] (dump_stack) from [<c0031154>] (__warn+0xf8/0x124)
      [  153.141056] [<c0031154>] (__warn) from [<c0031248>] (warn_slowpath_fmt+0x38/0x48)
      [  153.148580] [<c0031248>] (warn_slowpath_fmt) from [<c040fde0>] (clk_core_disable_lock+0x18/0x24)
      [  153.157413] [<c040fde0>] (clk_core_disable_lock) from [<c058f520>] (i2c_imx_probe+0x554/0x6ec)
      [  153.166076] [<c058f520>] (i2c_imx_probe) from [<c04b9178>] (platform_drv_probe+0x48/0x98)
      [  153.174297] [<c04b9178>] (platform_drv_probe) from [<c04b7298>] (really_probe+0x1d8/0x2c0)
      [  153.182605] [<c04b7298>] (really_probe) from [<c04b7554>] (driver_probe_device+0x5c/0x174)
      [  153.190909] [<c04b7554>] (driver_probe_device) from [<c04b58c8>] (bus_for_each_drv+0x44/0x8c)
      [  153.199480] [<c04b58c8>] (bus_for_each_drv) from [<c04b746c>] (__device_attach+0xa0/0x108)
      [  153.207782] [<c04b746c>] (__device_attach) from [<c04b65a4>] (bus_probe_device+0x88/0x90)
      [  153.215999] [<c04b65a4>] (bus_probe_device) from [<c04b6a04>] (deferred_probe_work_func+0x60/0x90)
      [  153.225003] [<c04b6a04>] (deferred_probe_work_func) from [<c004f190>] (process_one_work+0x204/0x634)
      [  153.234178] [<c004f190>] (process_one_work) from [<c004f618>] (worker_thread+0x20/0x484)
      [  153.242315] [<c004f618>] (worker_thread) from [<c0055c2c>] (kthread+0x118/0x150)
      [  153.249758] [<c0055c2c>] (kthread) from [<c00090b4>] (ret_from_fork+0x14/0x20)
      [  153.257006] Exception stack(0xdde43fb0 to 0xdde43ff8)
      [  153.262095] 3fa0:                                     00000000 00000000 00000000 00000000
      [  153.270306] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [  153.278520] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      [  153.285159] irq event stamp: 3323022
      [  153.288787] hardirqs last  enabled at (3323021): [<c0861c4c>] _raw_spin_unlock_irq+0x24/0x2c
      [  153.297261] hardirqs last disabled at (3323022): [<c040d7a0>] clk_enable_lock+0x10/0x124
      [  153.305392] softirqs last  enabled at (3322092): [<c000a504>] __do_softirq+0x344/0x540
      [  153.313352] softirqs last disabled at (3322081): [<c00385c0>] irq_exit+0x10c/0x128
      [  153.320946] ---[ end trace a506731ccd9bd703 ]---
      
      This endless clk warnings behaviour is well explained by Andrey Smirnov:
      
      "Allocating DMA after registering I2C adapter can lead to infinite
      probing loop, for example, consider the following scenario:
      
          1. i2c_imx_probe() is called and successfully registers an I2C
             adapter via i2c_add_numbered_adapter()
      
          2. As a part of i2c_add_numbered_adapter() new I2C slave devices
             are added from DT which results in a call to
             driver_deferred_probe_trigger()
      
          3. i2c_imx_probe() continues and calls i2c_imx_dma_request() which
             due to lack of proper DMA driver returns -EPROBE_DEFER
      
          4. i2c_imx_probe() fails, removes I2C adapter and returns
             -EPROBE_DEFER, which places it into deferred probe list
      
          5. Deferred probe work triggered in #2 above kicks in and calls
             i2c_imx_probe() again thus bringing us to step #1"
      
      So revert commit e1ab9a46 ("i2c: imx: improve the error handling in
      i2c_imx_dma_request()") and restore the old behaviour, in order to
      avoid regressions on existing setups.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
      Reported-by: default avatarRussell King <linux@armlinux.org.uk>
      Fixes: e1ab9a46 ("i2c: imx: improve the error handling in i2c_imx_dma_request()")
      Signed-off-by: default avatarFabio Estevam <festevam@gmail.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      e8c220fa
  4. May 27, 2019
  5. Apr 23, 2019
    • Anson Huang's avatar
      i2c: imx: correct the method of getting private data in notifier_call · d386bb90
      Anson Huang authored
      
      The way of getting private imx_i2c_struct in i2c_imx_clk_notifier_call()
      is incorrect, should use clk_change_nb element to get correct address
      and avoid below kernel dump during POST_RATE_CHANGE notify by clk
      framework:
      
      Unable to handle kernel paging request at virtual address 03ef1488
      pgd = (ptrval)
      [03ef1488] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Workqueue: events reduce_bus_freq_handler
      PC is at i2c_imx_set_clk+0x10/0xb8
      LR is at i2c_imx_clk_notifier_call+0x20/0x28
      pc : [<806a893c>]    lr : [<806a8a04>]    psr: a0080013
      sp : bf399dd8  ip : bf3432ac  fp : bf7c1dc0
      r10: 00000002  r9 : 00000000  r8 : 00000000
      r7 : 03ef1480  r6 : bf399e50  r5 : ffffffff  r4 : 00000000
      r3 : bf025300  r2 : bf399e50  r1 : 00b71b00  r0 : bf399be8
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 4e03004a  DAC: 00000051
      Process kworker/2:1 (pid: 38, stack limit = 0x(ptrval))
      Stack: (0xbf399dd8 to 0xbf39a000)
      9dc0:                                                       806a89e4 00000000
      9de0: ffffffff bf399e50 00000002 806a8a04 806a89e4 80142900 ffffffff 00000000
      9e00: bf34ef18 bf34ef04 00000000 ffffffff bf399e50 80142d84 00000000 bf399e6c
      9e20: bf34ef00 80f214c4 bf025300 00000002 80f08d08 bf017480 00000000 80142df0
      9e40: 00000000 80166ed8 80c27638 8045de58 bf352340 03ef1480 00b71b00 0f82e242
      9e60: bf025300 00000002 03ef1480 80f60e5c 00000001 8045edf0 00000002 8045eb08
      9e80: bf025300 00000002 03ef1480 8045ee10 03ef1480 8045eb08 bf01be40 00000002
      9ea0: 03ef1480 8045ee10 07de2900 8045eb08 bf01b780 00000002 07de2900 8045ee10
      9ec0: 80c27898 bf399ee4 bf020a80 00000002 1f78a400 8045ee10 80f60e5c 80460514
      9ee0: 80f60e5c bf01b600 bf01b480 80460460 0f82e242 bf383a80 bf383a00 80f60e5c
      9f00: 00000000 bf7c1dc0 80f60e70 80460564 80f60df0 80f60d24 80f60df0 8011e72c
      9f20: 00000000 80f60df0 80f60e6c bf7c4f00 00000000 8011e7ac bf274000 8013bd84
      9f40: bf7c1dd8 80f03d00 bf274000 bf7c1dc0 bf274014 bf7c1dd8 80f03d00 bf398000
      9f60: 00000008 8013bfb4 00000000 bf25d100 bf25d0c0 00000000 bf274000 8013bf88
      9f80: bf25d11c bf0cfebc 00000000 8014140c bf25d0c0 801412ec 00000000 00000000
      9fa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000
      9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
      [<806a893c>] (i2c_imx_set_clk) from [<806a8a04>] (i2c_imx_clk_notifier_call+0x20/0x28)
      [<806a8a04>] (i2c_imx_clk_notifier_call) from [<80142900>] (notifier_call_chain+0x44/0x84)
      [<80142900>] (notifier_call_chain) from [<80142d84>] (__srcu_notifier_call_chain+0x44/0x98)
      [<80142d84>] (__srcu_notifier_call_chain) from [<80142df0>] (srcu_notifier_call_chain+0x18/0x20)
      [<80142df0>] (srcu_notifier_call_chain) from [<8045de58>] (__clk_notify+0x78/0xa4)
      [<8045de58>] (__clk_notify) from [<8045edf0>] (__clk_recalc_rates+0x60/0xb4)
      [<8045edf0>] (__clk_recalc_rates) from [<8045ee10>] (__clk_recalc_rates+0x80/0xb4)
      Code: e92d40f8 e5903298 e59072a0 e1530001 (e5975008)
      ---[ end trace fc7f5514b97b6cbb ]---
      
      Fixes: 90ad2cbe ("i2c: imx: use clk notifier for rate changes")
      Signed-off-by: default avatarAnson Huang <Anson.Huang@nxp.com>
      Reviewed-by: default avatarDong Aisheng <aisheng.dong@nxp.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      d386bb90
  6. Apr 06, 2019
  7. Jan 22, 2019
  8. Jan 15, 2019
  9. Nov 27, 2018
  10. Aug 20, 2018
  11. Jul 24, 2018
  12. Jul 23, 2018
  13. May 29, 2018
    • Peter Rosin's avatar
      i2c: busses: make use of i2c_8bit_addr_from_msg · 30a64757
      Peter Rosin authored
      
      Because it looks neater.
      
      For diolan, this allows factoring out some code that is now common
      between if and else.
      
      For eg20t, pch_i2c_writebytes is always called with a write in
      msgs->flags, and pch_i2c_readbytes with a read.
      
      For imx, i2c_imx_dma_write and i2c_imx_write are always called with a
      write in msgs->flags, and i2c_imx_read with a read.
      
      For qup, qup_i2c_write_tx_fifo_v1 is always called with a write in
      qup->msg->flags.
      
      For stu300, also restructure debug output for resends, since that
      code as a result is only handling debug output.
      
      Reviewed-by: Guenter Roeck <linux@roeck-us.net> [diolan]
      Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [efm32 and imx]
      Acked-by: Linus Walleij <linus.walleij@linaro.org> [stu300]
      Signed-off-by: default avatarPeter Rosin <peda@axentia.se>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      30a64757
  14. May 24, 2018
  15. Apr 03, 2018
  16. Dec 12, 2017
  17. Dec 07, 2017
  18. Nov 27, 2017
  19. Oct 13, 2017
  20. Jun 22, 2017
  21. Feb 09, 2017
  22. Oct 25, 2016
  23. Sep 15, 2016
  24. Aug 22, 2016
  25. Apr 26, 2016
    • Oleksij Rempel's avatar
      i2c: imx: reduce load by using usleep_range instead of udelay · 2b899f34
      Oleksij Rempel authored
      
      Documentation/timers/timers-howto.txt recommends to use
      usleep_range on delays > 10usec. According to my test results
      with Neonode zForce touchscreen driver, usleep_range indeed
      reduces CPU load.
      
      Stats collected with "./perf record -a -g -F 1000 sleep 10"
      
      i2c-imx with udelay(50):
      34.19% 0.00% irq/220-Neonode [kernel.kallsyms] [k] irq_thread
          ---irq_thread
             |--33.75%--irq_thread_fn
             |    |--19.27%--0x7f08a878
             |    |     i2c_master_recv
             |    |     i2c_transfer
             |    |     __i2c_transfer
             |    |     i2c_imx_xfer
             |    |     |--11.71%--i2c_imx_trx_complete
             |    |     |--5.70%--i2c_imx_start <<<<----------------
             |    |     |     |--5.38%--__timer_const_udelay
             |    |     |     |      __timer_delay
             |    |     |     |      --5.07%--read_current_timer
      
      i2c-imx with usleep_range(50,100)
      29.08% 0.00% irq/220-Neonode  [kernel.kallsyms] [k] irq_thread
          ---irq_thread
             |--28.89%--irq_thread_fn
             |    |--17.21%--0x7f08a878
             |    |     i2c_master_recv
             |    |     |--17.14%--i2c_transfer
             |    |     |     __i2c_transfer
             |    |     |     i2c_imx_xfer
             |    |     |     |--14.29%--i2c_imx_trx_complete
             |    |     |     |--1.42%--i2c_imx_start <<<<----------
             |    |     |     |      |--0.71%--usleep_range
             |    |     |     |      |--0.53%--i2c_imx_bus_busy
      
      Signed-off-by: default avatarOleksij Rempel <linux@rempel-privat.de>
      Signed-off-by: default avatarDirk Behme <dirk.behme@de.bosch.com>
      Reviewed-by: default avatarVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      2b899f34
  26. Mar 03, 2016
  27. Jan 10, 2016
  28. Jan 04, 2016
  29. Jan 03, 2016
  30. Dec 09, 2015
  31. Nov 20, 2015
  32. Oct 23, 2015
Loading