public inbox for linux-tegra@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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