rt-mutex usage in i2c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have two questions:

- em28xx_i2c_xfer() in drivers/media/usb/em28xx/em28xx-i2c.c takes a
  rt_mutex lock. This struct i2c_algorithm's ->master_xfer callback.
  Why does it take an extra lock since it looks to me that it is
  protected by struct i2c_adapter's bus_lock already.

- i2c_transfer() has this piece:
  2091                 if (in_atomic() || irqs_disabled()) {
  2092                         ret = i2c_trylock_adapter(adap);

  is this irqs_disabled() is what bothers me and should not be there.
  pxa does a spin_lock_irq() which would enable interrupts on return /
  too early.
  mxs has a wait_for_completion() which needs irqs enabled _and_ makes
  in_atomic() problematic, too. I have't checked other drivers but the
  commit, that introduced it, does not explain why it is required.
  So _should_ this be invoked from an interrupt handler (for instance),
  then it would record the wrong process as the lock owner. This isn't
  problematic unless on SMP the owner gets boosted because a process
  with a higher priority needs the lock.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux