Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1451511
| From | Andrey Pronin <apronin@chromium.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 1/2] tpm: devicetree: document properties for cr50 |
| Date | 2016-07-27 23:10 +0200 |
| Message-ID | <rZEfw-4Gp-5@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <rWQGd-4wj-5@gated-at.bofh.it> <rWQGd-4wj-3@gated-at.bofh.it> <rX52x-5nW-9@gated-at.bofh.it> <rX5Fh-5EF-37@gated-at.bofh.it> <rXtoe-4vY-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Jul 21, 2016 at 04:03:12PM -0500, Rob Herring wrote: > On Wed, Jul 20, 2016 at 12:49:12PM -0700, Andrey Pronin wrote: > > On Wed, Jul 20, 2016 at 02:03:03PM -0500, Rob Herring wrote: > > > On Tue, Jul 19, 2016 at 08:41:24PM -0700, Andrey Pronin wrote: > > > > Hi Rob, > > > > > As I mentioned, there may be common properties. It doesn't seem you > > > looked, so I did: > > > > > > - spi-rx-delay-us - (optional) Microsecond delay after a read transfer. > > > - spi-tx-delay-us - (optional) Microsecond delay after a write transfer. > > > > > > Seems to me setting one or both of these should work for you. > > > > > > > Yes, good catch, my fault I didn't see those. > > But they are not exactly what I mean and need. I don't need delay after > > each read or write transfer. What is needed is a guaranteed time > > between transfers. > > > > So, if the next transaction doesn't come withing the next X ms (or us), > > we don't waste time on inserting a delays after this transaction at all. > > Following the description and always inserting a delay must work well > > for short microseconds-long delays. For longer milliseconds-long delays > > a different strategy of checking the time when the previous transaction > > was and only delaying if it was not too long ago is better. > > I'd guess that the intent is the same for all. A simple delay is > just much easier to implement. I would think implementing the more > sophisticated algorithm would work for all users. Perhaps with some > threshold for a simple delay. > > > Thus, I won't be able to re-use these properties anyways based on their > > current description in bindings/spi/spi-bus.txt. > > > > > > +- sleep-delay-ms: Time after the last SPI activity, after which the chip > > > > + may go to sleep. > > > > +- wake-start-delay-ms: Time after initiating wake up before the chip is > > > > + ready to accept commands over SPI. > > > > > > I also asked why these 2 can't be hard-coded in the driver? > > > > > > > Sorry, I just updated this patch description in v2 to indicate why they are not > > hard-coded, but didn't answer explicitly. As the firmware changes, a different > > revision of it can have a different time before it sleeps in its configuration, > > or the time it takes it to startup may be different. Thus, there's a way to > > set it here w/o changing the driver. > > The firmware and DT may not be updated in sync especially if you are > loading the firmware from the rootfs. Are you doing DT and firmware > updates without changing the kernel? > > Rob Hi Rob, Thanks for the feedback. I will hard-code those parameters in the driver instead of reading from DT. Thanks, Andrey
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: [PATCH v2 1/2] tpm: devicetree: document properties for cr50 Andrey Pronin <apronin@chromium.org> - 2016-07-27 23:10 +0200
csiph-web