From: Dmitry Osipenko <digetx@gmail.com>
To: Jon Hunter <jonathanh@nvidia.com>,
Bitan Biswas <bbiswas@nvidia.com>,
Laxman Dewangan <ldewangan@nvidia.com>,
Thierry Reding <treding@nvidia.com>,
linux-i2c@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, Peter Rosin <peda@axentia.se>,
Wolfram Sang <wsa@the-dreams.de>
Cc: Shardar Mohammed <smohammed@nvidia.com>,
Sowjanya Komatineni <skomatineni@nvidia.com>,
Mantravadi Karthik <mkarthik@nvidia.com>
Subject: Re: [PATCH V2] i2c: tegra: disable irq in tegra_i2c_xfer_msg
Date: Tue, 18 Jun 2019 21:34:08 +0300 [thread overview]
Message-ID: <28cd06ca-3bd4-87e1-6d52-504cd00e1adb@gmail.com> (raw)
In-Reply-To: <61c2dbcd-85f2-2094-7596-78ac01f55421@nvidia.com>
18.06.2019 12:13, Jon Hunter пишет:
>
> On 18/06/2019 09:42, Bitan Biswas wrote:
>> tegra_i2c_xfer_msg initiates the I2C transfer in DMA
>> or PIO mode. It involves steps that need FIFO register
>> access, DMA API calls like dma_sync_single_for_device, etc.
>> Tegra I2C ISR has calls to tegra_i2c_empty_rx_fifo in PIO mode
>> and in DMA/PIO mode writes different I2C registers including
>> I2C interrupt status. ISR cannot start processing
>> before the preparation step at tegra_i2c_xfer_msg is complete.
>> Hence, a synchronization between ISR and tegra_i2c_xfer_msg
>> is in place today using spinlock.
>>
>> Spinlock busy waits and can add avoidable delays.
>>
>> In this patch needed synchronization is achieved by disabling
>> I2C interrupt during preparation step and enabling interrupt
>> once preparation is over and spinlock is no longer needed.
> Sorry but I still don't understand the problem you are trying to solve.
> Yes spinlocks are busy waits but is this busy wait an actual problem? If
> so what is the problem with this?
There is no real problem here, the intent is to clean up the code more and that should
be mentioned in the commit message for clarity. This was actually my suggestion that
Bitan is now started to implement, which is very nice! It should be a good result in
the end.
> It appears that the spinlock was added to prevent error interrupts
> occurring until the transfer has started. If this is for error cases,
> then probably it is not often that the CPU is stuck busy waiting on the
> spinlock.
>
> Furthermore, in addition to the spinlock we also have calls to
> tegra_i2c_unmask_irq/tegra_i2c_mask_irq. Therefore, if we are going to
> change this it would seem like a good idea to consolidate the
> masking/unmasking of IRQs and the spinlock, if possible.
>
> Finally, I still see that we have a spinlock in the downstream kernels
> we are shipping and so I would prefer to see such a change also be
> tested in the downstream kernels we are releasing.
next prev parent reply other threads:[~2019-06-18 18:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 8:42 [PATCH V2] i2c: tegra: disable irq in tegra_i2c_xfer_msg Bitan Biswas
2019-06-18 9:13 ` Jon Hunter
2019-06-18 18:34 ` Dmitry Osipenko [this message]
2019-06-18 9:41 ` Peter Rosin
2019-06-18 18:26 ` Dmitry Osipenko
2019-06-19 8:58 ` Jon Hunter
2019-06-19 9:02 ` Dmitry Osipenko
2019-06-19 9:10 ` Dmitry Osipenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28cd06ca-3bd4-87e1-6d52-504cd00e1adb@gmail.com \
--to=digetx@gmail.com \
--cc=bbiswas@nvidia.com \
--cc=jonathanh@nvidia.com \
--cc=ldewangan@nvidia.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mkarthik@nvidia.com \
--cc=peda@axentia.se \
--cc=skomatineni@nvidia.com \
--cc=smohammed@nvidia.com \
--cc=treding@nvidia.com \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox