crb state transition question

crb state transition question

[Jerry Snitselaar]

How closely should the driver adhere to the state transitions documented
in the ptp spec? I think in an earlier patch Tomas mentioned that PTT
(at least some versions) was handling idle state management itself. With
something other than PTT coming along to use crb, I'm wondering if we
should be doing something like crb_cmd_ready at the beginning of
crb_send, and crb_go_idle at the end of crb_recv.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: crb state transition question

[Jarkko Sakkinen]

On Fri, Mar 24, 2017 at 04:09:40PM -0700, Jerry Snitselaar wrote:
> 
> How closely should the driver adhere to the state transitions documented
> in the ptp spec? I think in an earlier patch Tomas mentioned that PTT
> (at least some versions) was handling idle state management itself. With
> something other than PTT coming along to use crb, I'm wondering if we
> should be doing something like crb_cmd_ready at the beginning of
> crb_send, and crb_go_idle at the end of crb_recv.

There are pm_runtime calls in tpm_transmit and callbacks to tpm_crb. The
transition to powered state and back happens once per trasmission. This
works for all Intel platforms. I would consider fixing it if there was
a regression related to power gating in ARM64 for example.

Can't really even recall what was exactly said in the specification
about this. I took the timeouts from the spec basically (the power
gating patch was originally done by me and further refined by Tomas).

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot