From: Dmitry Osipenko <digetx@gmail.com>
To: Peter Rosin <peda@axentia.se>,
Sowjanya Komatineni <skomatineni@nvidia.com>,
"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
"jonathanh@nvidia.com" <jonathanh@nvidia.com>,
"mkarthik@nvidia.com" <mkarthik@nvidia.com>,
"smohammed@nvidia.com" <smohammed@nvidia.com>,
"talho@nvidia.com" <talho@nvidia.com>
Cc: "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH V15 3/6] i2c: tegra: fix maximum transfer size
Date: Fri, 8 Feb 2019 17:32:00 +0300 [thread overview]
Message-ID: <96a3955f-ef4f-e4df-4907-6ec760fad3fe@gmail.com> (raw)
In-Reply-To: <9e8f26bb-2159-6ca4-783e-91a73dac0823@axentia.se>
08.02.2019 17:12, Peter Rosin пишет:
> On 2019-02-08 13:46, Dmitry Osipenko wrote:
>> 08.02.2019 1:25, Dmitry Osipenko пишет:
>>>> 08.02.2019 1:16, Sowjanya Komatineni пишет:>
>>>>>> This is wrong, 65535 = 64 * 1024 - 1.
>>>>>>
>>>>>> Let's just use size-constants provided by kernel:
>>>>>>
>>>>>> static const struct i2c_adapter_quirks tegra_i2c_quirks = {
>>>>>> .flags = I2C_AQ_NO_ZERO_LEN,
>>>>>> .max_read_len = SZ_4K,
>>>>>> .max_write_len = SZ_4K - I2C_PACKET_HEADER_SIZE, };
>>>>>>
>>>>>> static const struct i2c_adapter_quirks tegra194_i2c_quirks = {
>>>>>> .flags = I2C_AQ_NO_ZERO_LEN,
>>>>>> .max_read_len = SZ_64K,
>>>>>> .max_write_len = SZ_64K - I2C_PACKET_HEADER_SIZE, };
>>>>>>
>>>>>>
>>>>>> I'll take a look at other patches later today, no need to send out new version right now.
>>>>>>
>>>>>>
>>>>>
>>>>> SIZE_64K is 0x00010000 (65536)
>>>>>
>>>>> msg len is u16 and max that can be set to msg.len is 65535
>>>
>>> Ah, okay. Then it looks about right, maybe it's time to change u16 to u32 in the I2C core.
>>>
>>
>> Here is my suggestion:
>>
>> 1) Use SZ_4K / SZ_64K that I suggested above.
>>
>> 2) Squash this patch into the DMA-patch.
>>
>> 3) Add another patch (before the DMA-patch) that changes max_read_len/max_write_len types to u32 in the include/linux/i2c.h
>
> That is a bit naive and will not fly since the I2C core has a max message
> size of 65535. Which is exposed to user space...
>
> Given the above, saying .max_read_len = 65535 a NOP (and is in fact omitted
> in places where it would be needed if the type is changed). I suggest that
> it is omitted here as well. But SZ_64K - I2C_PACKET_HEADER_SIZE is still
> needed of course. At least if I2C_PACKET_HEADER_SIZE is guaranteed to be
> non-zero?
Ah, I missed that message len is also u16 and then we indeed could just drop the "max_read_len" for T194. Thank you Peter.
Sowjanya, given the above, it probably better to define dma_buf max-size in the tegra_i2c_hw_feature.
next prev parent reply other threads:[~2019-02-08 14:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-07 21:47 [PATCH V15 1/6] i2c: tegra: sort all the include headers alphabetically Sowjanya Komatineni
2019-02-07 21:47 ` [PATCH V15 2/6] i2c: tegra: add bus clear Master Support Sowjanya Komatineni
2019-02-07 21:47 ` [PATCH V15 3/6] i2c: tegra: fix maximum transfer size Sowjanya Komatineni
2019-02-07 22:09 ` Dmitry Osipenko
2019-02-07 22:25 ` Dmitry Osipenko
2019-02-08 12:46 ` Dmitry Osipenko
2019-02-08 14:12 ` Peter Rosin
2019-02-08 14:32 ` Dmitry Osipenko [this message]
2019-02-08 15:25 ` Sowjanya Komatineni
2019-02-08 15:44 ` Dmitry Osipenko
2019-02-07 21:47 ` [PATCH V15 4/6] i2c: tegra: Add DMA support Sowjanya Komatineni
2019-02-08 12:47 ` Dmitry Osipenko
2019-02-08 15:49 ` Sowjanya Komatineni
2019-02-08 15:55 ` Sowjanya Komatineni
2019-02-08 15:58 ` Sowjanya Komatineni
2019-02-08 16:15 ` Dmitry Osipenko
2019-02-07 21:47 ` [PATCH V15 5/6] i2c: tegra: update transfer timeout Sowjanya Komatineni
2019-02-07 21:47 ` [PATCH V15 6/6] i2c: tegra: add i2c interface timing support Sowjanya Komatineni
2019-02-08 12:53 ` Dmitry Osipenko
2019-02-08 13:00 ` 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=96a3955f-ef4f-e4df-4907-6ec760fad3fe@gmail.com \
--to=digetx@gmail.com \
--cc=jonathanh@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=talho@nvidia.com \
--cc=thierry.reding@gmail.com \
/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