From: Dmitry Osipenko <digetx@gmail.com>
To: Akhil R <akhilrajeev@nvidia.com>,
Dmitry Osipenko <dmitry.osipenko@collabora.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"christian.koenig@amd.com" <christian.koenig@amd.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
Laxman Dewangan <ldewangan@nvidia.com>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
"wsa@kernel.org" <wsa@kernel.org>
Subject: Re: [PATCH RESEND 1/2] i2c: tegra: Add GPCDMA support
Date: Mon, 22 Aug 2022 23:33:23 +0300 [thread overview]
Message-ID: <fac10841-1682-845f-3e4a-5668f59caed0@gmail.com> (raw)
In-Reply-To: <SJ1PR12MB63396DC508F63807F1CE9901C0719@SJ1PR12MB6339.namprd12.prod.outlook.com>
22.08.2022 13:29, Akhil R пишет:
>> On 8/22/22 09:56, Akhil R wrote:
>>>> 19.08.2022 18:15, Dmitry Osipenko пишет:
>>>>> 19.08.2022 15:23, Akhil R пишет:
>>>>>> if (of_device_is_compatible(np, "nvidia,tegra210-i2c-vi"))
>>>>>> i2c_dev->is_vi = true;
>>>>>> + else
>>>>>> + i2c_dev->dma_support = !!(of_find_property(np, "dmas",
>>>>>> + NULL));
>>>>>
>>>>> 1. You leak the np returned by of_find_property().
>>>>>
>>>>> 2. There is device_property_read_bool() for this kind of
>>>>> property-exists checks.
>>> Okay. I went by the implementation in of_dma_request_slave_channel() to
>>> check 'dmas'.
>>>
>>>>>
>>>>> 3. If "dmas" is missing in DT, then dma_request_chan() should return
>>>>> NULL and everything will work fine. I suppose you haven't tried to
>>>>> test this code.
>>>>
>>>> Although, no. It should return ERR_PTR(-ENODEV) and then you should check
>>>> the return code.
>>> Yes. Agree that it is more agnostic to check for ERR_PTR(-ENODEV). But since I
>>> call tegra_init_dma() for every large transfer until DMA is initialized, wouldn't
>>> it be better to have a flag inside the driver so that we do not have to go
>> through
>>> so many functions for every attempted DMA transaction to find out that the
>> DT
>>> properties don't exist?
>>>
>>> Shall I just put i2c_dev->dma_support = true here since DMA is supported by
>>> hardware? It would turn false if dma_request_chan() returns something other
>>> than -EPROBE_DEFER.
>>>
>>> if (of_device_is_compatible(np, "nvidia,tegra210-i2c-vi"))
>>> i2c_dev->is_vi = true;
>>> + else
>>> + i2c_dev->dma_support = true;
>>
>> The code already has dma_mode for that. I don't see why another variable
>> is needed.
>>
>> Either add new generic dma_request_chan_optional() that will return NULL
>> if channel is not available and make Tegra I2C driver to use it, or
>> handle the error code returned by dma_request_chan().
>
> Let me elaborate my thoughts.
>
> The function tegra_i2c_init_dma() is also called inside tegra_i2c_xfer_msg() if
> DMA is not initialized before, i.e. if (!i2c_dev->dma_buf).
This is not true
i2c_dev->dma_mode=false if !i2c_dev->dma_buf and that's it
https://elixir.bootlin.com/linux/v6.0-rc2/source/drivers/i2c/busses/i2c-tegra.c#L1253
tegra_i2c_init_dma() is invoked only during probe
> So, if suppose there is no DT entry for dmas, the driver would have to go take the
> path tegra_i2c_init_dma() -> dma_request_chan() -> of_*() apis -> ... and then figure
> out that DMA is not supported. This would happen for each transfer of size larger than
> I2C_PIO_MODE_PREFERRED_LEN.
>
> To avoid this, I am looking for a variable/flag which can indicate if the driver should attempt
> to configure DMA or not. I didn't quite get the idea if dma_mode can be extended to support
> this, because it is updated based on xfer_size on each transfer. My idea of i2c_dev->dma_support
> is that it will be constant after the probe().
next prev parent reply other threads:[~2022-08-22 20:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 12:23 [PATCH RESEND 0/2] Add GPCDMA support to Tegra234 I2C Akhil R
2022-08-19 12:23 ` [PATCH RESEND 1/2] i2c: tegra: Add GPCDMA support Akhil R
2022-08-19 15:15 ` Dmitry Osipenko
2022-08-19 15:27 ` Dmitry Osipenko
2022-08-22 6:56 ` Akhil R
2022-08-22 9:45 ` Dmitry Osipenko
2022-08-22 10:29 ` Akhil R
2022-08-22 20:33 ` Dmitry Osipenko [this message]
2022-08-22 21:08 ` Dmitry Osipenko
2022-08-23 5:17 ` Akhil R
2022-08-23 8:39 ` Dmitry Osipenko
2022-08-23 8:45 ` Dmitry Osipenko
2022-08-23 12:55 ` Akhil R
2022-08-23 13:32 ` Dmitry Osipenko
2022-08-25 16:41 ` Akhil R
2022-09-01 14:40 ` Thierry Reding
2022-09-02 11:25 ` Dmitry Osipenko
2022-08-19 12:23 ` [PATCH RESEND 2/2] arm64: tegra: Add GPCDMA support for Tegra234 I2C Akhil R
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=fac10841-1682-845f-3e4a-5668f59caed0@gmail.com \
--to=digetx@gmail.com \
--cc=akhilrajeev@nvidia.com \
--cc=christian.koenig@amd.com \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.osipenko@collabora.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=robh+dt@kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=thierry.reding@gmail.com \
--cc=wsa@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.