[PATCH 1/2] Revert "rockchip: spi: fix off-by-one in chunk size computation"

Kever Yang kever.yang at rock-chips.com
Mon Dec 23 03:28:47 CET 2019


On 2019/12/21 下午3:32, Jagan Teki wrote:
> Hi Philipp,
>
> On Wed, Dec 11, 2019 at 7:10 PM Philipp Tomsich
> <philipp.tomsich at theobroma-systems.com> wrote:
>>
>>
>>> On 11.12.2019, at 14:26, Jagan Teki <jagan at amarulasolutions.com> wrote:
>>>
>>> The maximum transfer length (in a single transaction) for the Rockchip
>>> SPI controller is 64Kframes (i.e. 0x10000 frames) of 8bit or 16bit
>>> frames and is encoded as (num_frames - 1) in CTRLR1.
>>>
>>> So the 0x10000 is offset value for 64K but the actual size value would
>>> be 'minus 1' from 0x10000.
>> NAK. Please see 2 code lines below your change to see that the “minus 1”
>> is applied there… so a todo of 0x10000 will write 0xffff to regs->ctrlr1.
>>
>> The problem must be somewhere else and this patch will only mask the
>> underlying issue.
> Please check the below changes. the max transfer size is 64K - 1 which
> is 0xffff and we need to write -1 of this to cr1.

Yep, the counter is 16bit, and the actual max size will be 0xffff and 
the max available value in reg should

be 0xffff-1.


Thanks,

- Kever

>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/spi/spi-rockchip.c?id=5185a81c02d4118b11e6cb7b5fbf6f15ff7aff90
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/spi/spi-rockchip.c?id=04b37d2d02c0a5ae2f4e59326ef6deaff18e0456
>
>




More information about the U-Boot mailing list