| Message ID | 20200831202303.15391-1-digetx@gmail.com |
|---|---|
| Headers | show |
| Series | Improvements for Tegra I2C driver | expand |
On Mon, Aug 31, 2020 at 11:22:51PM +0300, Dmitry Osipenko wrote: > Hello! > > This series performs a small refactoring of the Tegra I2C driver code and > hardens the atomic-transfer mode. > > Dmitry Osipenko (12): > i2c: tegra: Make tegra_i2c_flush_fifos() usable in atomic transfer > i2c: tegra: Add missing newline before returns > i2c: tegra: Clean up messages in the code > i2c: tegra: Don't ignore tegra_i2c_flush_fifos() error > i2c: tegra: Use reset_control_reset() > i2c: tegra: Improve formatting of function variables > i2c: tegra: Use dev_err_probe() > i2c: tegra: Runtime PM always available on Tegra > i2c: tegra: Clean up probe function > i2c: tegra: Drop '_timeout' from wait/poll function names > i2c: tegra: Remove likely/unlikely from the code > i2c: tegra: Factor out error recovery from tegra_i2c_xfer_msg() For all, but #3 and #9: Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> BTW, I wonder if you could expose i2c_in_atomic_xfer_mode() and use it to differentiate atomic_xfer from normal and get rid of the internal flag and .master_xfer_atomic callback. Best Regards, Michał Mirosław
03.09.2020 00:20, Michał Mirosław пишет: > BTW, I wonder if you could expose i2c_in_atomic_xfer_mode() and use it > to differentiate atomic_xfer from normal and get rid of the internal > flag and .master_xfer_atomic callback. The atomic transfer uses 90% of the code path that a non-atomic transfer uses. I don't see how it could be exposed without duplicated lots of the code, unless I'm not missing what you're suggesting.
On Thu, Sep 03, 2020 at 04:12:13AM +0300, Dmitry Osipenko wrote: > 03.09.2020 00:20, Michał Mirosław пишет: > > BTW, I wonder if you could expose i2c_in_atomic_xfer_mode() and use it > > to differentiate atomic_xfer from normal and get rid of the internal > > flag and .master_xfer_atomic callback. > > The atomic transfer uses 90% of the code path that a non-atomic transfer > uses. I don't see how it could be exposed without duplicated lots of the > code, unless I'm not missing what you're suggesting. The I2C core falls back to .master_xfer even in atomic mode if .master_xfer_atomic is NULL, so what I'm suggesting is to make i2c_in_atomic_xfer_mode() public (from i2c-core.h) and use it in normal .master_xfer to choose atomic wait variants. Best Regards, Michał Mirosław
03.09.2020 19:47, Michał Mirosław пишет: > On Thu, Sep 03, 2020 at 04:12:13AM +0300, Dmitry Osipenko wrote: >> 03.09.2020 00:20, Michał Mirosław пишет: >>> BTW, I wonder if you could expose i2c_in_atomic_xfer_mode() and use it >>> to differentiate atomic_xfer from normal and get rid of the internal >>> flag and .master_xfer_atomic callback. >> >> The atomic transfer uses 90% of the code path that a non-atomic transfer >> uses. I don't see how it could be exposed without duplicated lots of the >> code, unless I'm not missing what you're suggesting. > > The I2C core falls back to .master_xfer even in atomic mode if > .master_xfer_atomic is NULL, so what I'm suggesting is to make > i2c_in_atomic_xfer_mode() public (from i2c-core.h) and use it in > normal .master_xfer to choose atomic wait variants. Okay, I see now. But the I2C core prints a noisy warning if master_xfer_atomic is NULL in atomic transfer, so I'm not sure whether changing all that code will bring much benefits to us and anyone else. It's a bit too questionable change to me, but maybe I'm still missing something. Will be great if you could provide an example patch.