Skip to content

L
linux
Switch branch/tag
  1. 22 Apr, 2016 5 commits
  3. 16 Apr, 2016 2 commits
  5. 14 Apr, 2016 4 commits
  7. 13 Apr, 2016 2 commits
  9. 12 Apr, 2016 4 commits
    • Shardar Shariff Md's avatar
      i2c: tegra: enable multi master mode for tegra210 · 497fbe24
      Shardar Shariff Md authored 
      Enable multi-master mode in I2C_CNFG reg based on hw features.
Using single/multi-master mode bit introduced for Tegra210,
whereas multi-master mode is enabled by default in HW for T124 and
earlier Tegra SOC. Enabling this bit doesn't explicitly start
treating the bus has having multiple masters, but will start
checking for arbitration lost and reporting when it occurs.

The Tegra210 I2C controller supports single/multi master mode.
Add chipdata for Tegra210 and its compatibility string so that
Tegra210 will select data that enables multi master mode correctly.

Do below prerequisites for multi-master bus if "multi-master"
dt property entry is added.
 1. Enable 1st level clock always set.
 2. Disable 2nd level clock gating (slcg which
    is supported from T124 SOC and later chips)
Signed-off-by: default avatarShardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      497fbe24
    • Jarkko Nikula's avatar
      i2c: i801: Add runtime PM support with autosuspend · a7401ca5
      Jarkko Nikula authored 
      Allow runtime PM so that PM and PCI core can put the device into low-power
state when idle and resume it back when needed in those platforms that
support PM for i801 device.

Enable also autosuspend with 1 second delay in order to not needlessly
toggle power state on and off if there are multiple transactions during
short time.

Device is resumed at the beginning of bus access and marked idle ready
for autosuspend at the end of it.
Signed-off-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: default avatarReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      a7401ca5
    • Jarkko Nikula's avatar
      i2c: i801: Convert to struct dev_pm_ops for suspend/resume · 2ee73c48
      Jarkko Nikula authored 
      Stop using legacy PCI PM support and convert to standard dev_pm_ops.
This provides more straightforward path to add runtime PM.

While at it remove explicit PCI power state control and configuration space
save/restore as the PCI core does it.
Signed-off-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: default avatarReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      2ee73c48
    • Linus Walleij's avatar
      i2c: let I2C masters ignore their children for PM · 04f59143
      Linus Walleij authored 
      When using a certain I2C device with runtime PM enabled on
a certain I2C bus adaper the following happens:

struct amba_device *foo
   \
   struct i2c_adapter *bar
      \
      struct i2c_client *baz

The AMBA device foo has its device PM struct set to ignore
children with pm_suspend_ignore_children(&foo->dev, true).
This makes runtime PM work just fine locally in the driver:
the fact that devices on the bus are suspended or resumed
individually does not affect its operation, and the hardware
does not power up unless transferring messages.

However this child ignorance property is not inherited into
the struct i2c_adapter *bar.

On system suspend things will work fine.

On system resume the following annoying phenomenon occurs:

- In the pm_runtime_force_resume() path of
  struct i2c_client *baz, pm_runtime_set_active(&baz->dev); is
  eventually called.

- This becomes __pm_runtime_set_status(&baz->dev, RPM_ACTIVE);

- __pm_runtime_set_status() detects that RPM state is changed,
  and checks whether the parent is:
  not active (RPM_ACTIVE) and not ignoring its children
  If this happens it concludes something is wrong, because
  a parent that is not ignoring its children must be active
  before any children activate.

- Since the struct i2c_adapter *bar does not ignore
  its children, the PM core thinks that it must indeed go
  online before its children, the check bails out with
  -EBUSY, i.e. the i2c_client *baz thinks it can't work
  because it's parent is not online, and it respects its
  parent.

- In the driver the .resume() callback returns -EBUSY from
  the runtime_force_resume() call as per above. This leaves
  the device in a suspended state, leading to bad behaviour
  later when the device is used. The following debug
  print is made with an extra printg patch but illustrates
  the problem:

[   17.040832] bh1780 2-0029: parent (i2c-2) is not active
               parent->power.ignore_children = 0
[   17.040832] bh1780 2-0029: pm_runtime_force_resume:
               pm_runtime_set_active() failed (-16)
[   17.040863] dpm_run_callback():
               pm_runtime_force_resume+0x0/0x88 returns -16
[   17.040863] PM: Device 2-0029 failed to resume: error -16

Fix this by letting all struct i2c_adapter:s ignore their
children: i2c children have no business doing keeping
their parents awake: they are completely autonomous
devices that just use their parent to talk, a usecase
which must be power managed in the host on a per-message
basis.
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      04f59143
  11. 11 Apr, 2016 22 commits
  13. 10 Apr, 2016 1 commit
    • Linus Torvalds's avatar
      Revert "ext4: allow readdir()'s of large empty directories to be interrupted" · 9f2394c9
      Linus Torvalds authored 
      This reverts commit 1028b55b.

It's broken: it makes ext4 return an error at an invalid point, causing
the readdir wrappers to write the the position of the last successful
directory entry into the position field, which means that the next
readdir will now return that last successful entry _again_.

You can only return fatal errors (that terminate the readdir directory
walk) from within the filesystem readdir functions, the "normal" errors
(that happen when the readdir buffer fills up, for example) happen in
the iterorator where we know the position of the actual failing entry.

I do have a very different patch that does the "signal_pending()"
handling inside the iterator function where it is allowable, but while
that one passes all the sanity checks, I screwed up something like four
times while emailing it out, so I'm not going to commit it today.

So my track record is not good enough, and the stars will have to align
better before that one gets committed.  And it would be good to get some
review too, of course, since celestial alignments are always an iffy
debugging model.

IOW, let's just revert the commit that caused the problem for now.
Reported-by: default avatarGreg Thelen <gthelen@google.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9f2394c9
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7