>Nothing ever restores the constraints if a clock is specified again, and >in general it's odd that the enable/disable don't match up - if we're >setting variable constraints I'd expect that in the freq == 0 case we >should be setting ->sysclk_constraints to NULL rather than the contents. >Indeed, we'll segfault here if the frequency is set to 0 without having >first been set to some actual value. It's also bad to modify static >data potentially shared between multiple instances of the device in a >system. > >Having said all that though I'm not clear why we're doing this >constraint stuff at all, we never reference sysclk_constraints during >startup and teardown and you'd usually do this because you want to set >constraints that depend on the sysclk but this is just a constant set of >constraints that should be set in the DAI desription. Comes from 8316.c. Will remove the constraints. Will submit a patch later to remove the constraints in es8316.c. We can assume that the producer(master) provides correct mclk(sysclk) rate. >>> One question on the interrupt handling: should there be an interrupt >>> disable on suspend and conversely an interrupt enable on resume? >> >> That shouldn't be needed (in general the interrupt enable/disable stuff >> shouldn't be needed at all). > >isn't there a risk of an interrupt being triggered after all the jack >detection resources are disabled? The jack detection resources are only disabled after codec power down?
