| Message ID | 20241002112020.23913-1-eichest@gmail.com |
|---|---|
| Headers | show |
| Series | i2c: imx: prevent rescheduling in non-dma mode | expand |
On Wed, Oct 2, 2024, at 11:19, Stefan Eichenberger wrote: > From: Stefan Eichenberger <stefan.eichenberger@toradex.com> > > Use the relaxed version of readb and writeb to reduce overhead. It is > safe to use the relaxed version because we either do not rely on dma > completion, or we use a dma callback to ensure that the dma transfer is > complete before we continue. I would still consider this a bug in general, you should never default to the unsafe variants. If there is a codepath that needs the barrierless version, please add imx_i2c_write_reg_relaxed()/imx_i2c_read_reg_relaxed() helpers that use those only in the places where it makes a measurable difference, with a comment that explains the usage. Arnd
On Wed, Oct 2, 2024, at 13:08, Stefan Eichenberger wrote: > On Wed, Oct 02, 2024 at 11:51:22AM +0000, Arnd Bergmann wrote: >> On Wed, Oct 2, 2024, at 11:19, Stefan Eichenberger wrote: >> > From: Stefan Eichenberger <stefan.eichenberger@toradex.com> >> > >> > Use the relaxed version of readb and writeb to reduce overhead. It is >> > safe to use the relaxed version because we either do not rely on dma >> > completion, or we use a dma callback to ensure that the dma transfer is >> > complete before we continue. >> >> I would still consider this a bug in general, you should >> never default to the unsafe variants. >> >> If there is a codepath that needs the barrierless version, >> please add imx_i2c_write_reg_relaxed()/imx_i2c_read_reg_relaxed() >> helpers that use those only in the places where it makes >> a measurable difference, with a comment that explains >> the usage. > > I added the patch because of the following dicussion: > https://lore.kernel.org/linux-i2c/ZpVWXlR6j2i0ZtVQ@lizhi-Precision-Tower-5810/ > > I can't determine if the relaxed version improves performance. The > 'normal' version worked well for our use case too. Therefore, dropping > the change would be acceptable for us. Another potential solution could > be to use the relaxed version only inside the ISR. Would that be an > acceptable solution? What is your impression, Frank Li > <Frank.Li@nxp.com>? I'm pretty sure that Frank meant to use readb_relaxed()/writeb_relaxed() inside of the FIFO access loop, not for everything else. This makes a lot of sense, since the FIFO read in particular is clearly performance sensitive and already serialized by the implied control dependency. If you can read multiple bytes, the best interface to use would in fact be readsb() or possibly readsl() to read four bytes with each access. It appears that you did not implement the suggestion to read the entire FIFO though, so you can probably just skip the _relaxed() change entirely. Arnd
On Wed, Oct 02, 2024 at 01:36:04PM +0000, Arnd Bergmann wrote: > On Wed, Oct 2, 2024, at 13:08, Stefan Eichenberger wrote: > > On Wed, Oct 02, 2024 at 11:51:22AM +0000, Arnd Bergmann wrote: > >> On Wed, Oct 2, 2024, at 11:19, Stefan Eichenberger wrote: > >> > From: Stefan Eichenberger <stefan.eichenberger@toradex.com> > >> > > >> > Use the relaxed version of readb and writeb to reduce overhead. It is > >> > safe to use the relaxed version because we either do not rely on dma > >> > completion, or we use a dma callback to ensure that the dma transfer is > >> > complete before we continue. > >> > >> I would still consider this a bug in general, you should > >> never default to the unsafe variants. > >> > >> If there is a codepath that needs the barrierless version, > >> please add imx_i2c_write_reg_relaxed()/imx_i2c_read_reg_relaxed() > >> helpers that use those only in the places where it makes > >> a measurable difference, with a comment that explains > >> the usage. > > > > I added the patch because of the following dicussion: > > https://lore.kernel.org/linux-i2c/ZpVWXlR6j2i0ZtVQ@lizhi-Precision-Tower-5810/ > > > > I can't determine if the relaxed version improves performance. The > > 'normal' version worked well for our use case too. Therefore, dropping > > the change would be acceptable for us. Another potential solution could > > be to use the relaxed version only inside the ISR. Would that be an > > acceptable solution? What is your impression, Frank Li > > <Frank.Li@nxp.com>? > > I'm pretty sure that Frank meant to use readb_relaxed()/writeb_relaxed() > inside of the FIFO access loop, not for everything else. This > makes a lot of sense, since the FIFO read in particular is > clearly performance sensitive and already serialized by the > implied control dependency. > > If you can read multiple bytes, the best interface to use > would in fact be readsb() or possibly readsl() to read > four bytes with each access. > > It appears that you did not implement the suggestion to > read the entire FIFO though, so you can probably just skip > the _relaxed() change entirely. This makes sense, it appears this was a misunderstanding. If no one objects, I will drop the patch in the next version. Thank you for the clarification. Regards, Stefan
On Wed, Oct 02, 2024 at 04:40:32PM +0200, Lucas Stach wrote: > Am Mittwoch, dem 02.10.2024 um 13:19 +0200 schrieb Stefan Eichenberger: > > From: Stefan Eichenberger <stefan.eichenberger@toradex.com> > > > > According to the i.MX8M Mini reference manual chapter "16.1.4.2 > > Generation of Start" it is only necessary to poll for bus busy and > > arbitration lost in multi master mode. This helps to avoid rescheduling > > while the i2c bus is busy and avoids SMBus devices to timeout. > > > This is a backward incompatible change, as far as I can see. Until now > the driver would properly handle a multi-mastered bus, without any > specific configuration. Now it requires the new multi-master DT > property to be set, which isn't even documented in the binding to be > understood by this driver. > > Are you sure that every single instance of a i.MX i2c bus is only > single mastered? > > If this is a worthwhile performance improvement I guess you need to > flip the logic around by adding a new single-master DT property (or > something along those lines), which should go through proper DT binding > review. You can then use this property for boards/busses to opt into > skipping the arbitration lost check. According to the discussion here the property documentation should not be added: https://lore.kernel.org/linux-i2c/2bbddaxyjkxfmlgmq3yqcbzo7dsb2pq5bvdatk2y4ig4iintkt@35btqkdv7sy3/ However, the point regarding single-master and multi-master is correct. We also discussed this internally and assumed the single-master use case is more likely to be the default and that this patch series would fix issues for other devices out there. However, your point is valid and if preferred I can change it to single-master with the next version. Francesco Dolcini <francesco.dolcini@toradex.com> I think you once had a discussion regarding multi master mode for i2c on i.MX devices? Maybe you can remember the details? Regards, Stefan