On Wed, Sep 30, 2020 at 01:48:15PM -0700, James Bottomley wrote: > On Wed, 2020-09-30 at 18:37 +0300, Jarkko Sakkinen wrote: > > On Wed, Sep 30, 2020 at 07:54:58AM -0700, James Bottomley wrote: > > > On Wed, 2020-09-30 at 05:16 +0300, Jarkko Sakkinen wrote: > > > > On Mon, Sep 28, 2020 at 03:11:39PM -0700, James Bottomley wrote: > > > > > On Sun, 2020-09-27 at 22:59 -0700, Hao Wu wrote: > > > > > [...] > > > > > > > However, there is another possibility: it's something to do > > > > > > > with the byte read; I notice you don't require the same > > > > > > > slowdown for the burst count read, which actually reads the > > > > > > > status register and burst count as a read32. If that > > > > > > > really is the case, for the atmel would substituting a > > > > > > > read32 and just throwing the upper bytes away in > > > > > > > tpm_tis_status() allow us to keep the current timings? I > > > > > > > can actually try doing this and see if it fixes my nuvoton. > > > > > > > > > > > > If would be helpful if you can find the solution without > > > > > > reducing performance. I think it is a separate problem to > > > > > > address though. Maybe not worth to mix them in the same fix. > > > > > > > > > > Well, if it works, no other fix is needed. > > > > > > > > > > This is what I'm currently trying out on my nuvoton with the > > > > > timings reverted to being those in the vanilla kernel. So far > > > > > it hasn't crashed, but I haven't run it for long enough to be > > > > > sure yet. > > > > > > > > > > James > > > > > > > > OK, so the bus does not like one byte reads but prefers full (32- > > > > bit) word reads? I.e. what's the context? > > > > > > It's not supported by anything in the spec just empirical > > > observation. However, the spec says the status register is 24 > > > bits: the upper 16 being the burst count. When we read the whole > > > status register, including the burst count, we do a read32. I > > > observed that the elongated timing was only added for the read8 > > > code not the read32 which supports the theory that the former > > > causes the Atmel to crash but the latter doesn't. Of course it's > > > always possible that probabilistically the Atmel is going to crash > > > on the burst count read, but that's exercised far less than the > > > status only read. > > > > This paragraph is good enough explanation for me. Can you include it > > to the final commit as soon as we hear how your fix works for Hao? > > Sure. I'm afraid I have to report that it didn't work for me. My > Nuvoton is definitely annoyed by the frequency of the prodding rather > than the register width. Sorry, this might have been stated at some point but what type of bus is it connected with? Does it help in any way to tune the frequency? I also wonder if we could adjust the frequency dynamically. I.e. start with optimistic value and lower it until finding the sweet spot. /Jarkko
