Hi Andrew,
On Mon, Oct 16, 2017 at 2:48 PM, Andrew Worsley <amworsley@xxxxxxxxx> wrote:
> Thanks I think I know understand how this transfer register is set up.
> I will add some diagnostic printk's to track down exactly how it is
> failing and get back to you.
>
> Yes it is zynq. The test case is large (128 byte) transfers from a
> tpm to fill an rng driver. I just pull large amounts of data via dd.
>
> It may depend on the i2c slave being willing to just respond to
> requests that read arbitrary amounts of data. In this case the TPM
> appeared to generate FF when requested for more data than was in the
> TPM_RANDOM request.
>
>
>
> On 16 October 2017 at 16:55, Harini Katakam
> <harinikatakamlinux@xxxxxxxxx> wrote:
>> Hi Andrew,
>>
>> On Sat, Oct 14, 2017 at 12:16 AM, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote:
> .....
>>>
>>> So, let's add Harini Katakam to CC who implemented this. But I'd be
>>> happy for anyone from Xilinx to respond...
>>
>> The workaround you are referring to is implemented under
>> "if (cdns_is_holdquirk(id, hold_quirk)) {"
>> and should not apply to your case of 128 byte transfer at all.
>
> Ah I can see the logic now. If the transfer is small (< 250 or so
> bytes) it will just write it into the transfer register. Yes my
> transfers are only 128 + some TPM related headers ( not big I expect).
> ....
>
>
>>
>> The specific place you have problem is under the loop
>> where RX data valid is being checked and ideally, that
>> buffer should never be written with more data than requested -
>> because no. of bytes requested is written to transfer size register,
>> the same is the amount the controller (master) fetches and
>> RX data valid remains set only for that duration.
>
> If the transfer register was set with the
Yes, this is assuming the transfer size register was not set inittially
or later with more byted than required.
>>
>> Are you using Zynq?
>> I'm not working on this anymore but we could take a look at
>> your error if we are able to reproduce it.
>> Could you please provide more details of your application and
>> setup?
>>
>> Regards,
>> Harini
>
> Yes - I will get back to you with more details and further debugging
> around exactly how it is failing.
>
> Assuming it is not obvious how to fix it - perhaps I can try setting
> the transfer register to zero when it hits the end of the transfer?
> (if recv_count == 0).
Yes, that can be done as a workaround but ideally, the transfer
size register should have decremented to zero by this point.
>
> Thanks very much Harini - that was just the pointer I needed to
> follow the code.
Thanks for the information - please let me know what you find.
Regards,
Harini
