On 12/10/2014 10:34 AM, Lars-Peter Clausen wrote:
On 12/05/2014 01:37 PM, Mike Looijmans wrote:
If the master clock supports programmable rates, program it to generate the desired frequency. Only apply constraints when the clock is fixed. This allows proper clock generation for both 44100 and 48000 Hz based sampling rates if the platform supports it.
The clock frequency must be set before enabling it. Enabling the clock was done in "startup", but that occurs before "hw_params" where the rate is known. Enabling a programmable clock without first setting a valid frequency may harm the system. Move the clock start to the hw_params routine, and keep track of whether the clock has been started, because shutdown may be called without having called hw_params first. Starting the clock and enabling the SPDIF output AFTER programming the dividers is a more logical order anyway.
To detect if the source clock is fixed, the driver calls clk_round_rate for two frequencies. If the results are equal, or if the call returns an error, the driver assumes the clock is fixed.
Signed-off-by: Mike Looijmans mike.looijmans@topic.nl
Hi,
Sorry for the delay.
[...]
- /* Try to set the master clock */
- clk_set_rate(spdif->clk_ref, rate * 128);
clkdiv = DIV_ROUND_CLOSEST(clk_get_rate(spdif->clk_ref), rate * 64 * 2) - 1; clkdiv <<= AXI_SPDIF_CTRL_CLKDIV_OFFSET;@@ -103,6 +108,14 @@ static int axi_spdif_hw_params(struct snd_pcm_substream *substream, regmap_update_bits(spdif->regmap, AXI_SPDIF_REG_CTRL, AXI_SPDIF_CTRL_CLKDIV_MASK, clkdiv);
- ret = clk_prepare_enable(spdif->clk_ref);
I'm still not convinced this is the right place. I do see your point. But it just feels wrong to enable the clock in hw_params. It's a bit of a dilemma. the startup callback is to early, hw_params is the wrong place and we can't put it in the trigger callback as the trigger callback can not sleep.
The clock interface suggests that we should do the clk_prepare in hw_params and the clk_enable in trigger then, since clk_prepare may sleep but clk_enable cannot. Which would complicate the clock state housekeeping because I'd have to keep track of prepare and enable states separately.
(Imagine the housekeeping on a board that could have two codecs running on one DAI using the clock generated by a third codec... I never even bothered to submit that...)
But in any way hwparmas can be called multiple times, so you need to handle the case where the clock is already enabled.
A simple "if (spdif->clk_ref_running)" check would fix that. I wasn't aware of that though, I thought there'd be a shutdown before another hw_params.
- if (ret)
return ret;- spdif->clk_ref_running = true;
- regmap_update_bits(spdif->regmap, AXI_SPDIF_REG_CTRL,
AXI_SPDIF_CTRL_TXEN, AXI_SPDIF_CTRL_TXEN);This should probably be moved to the trigger callback though.
I'll create a v3.
Met vriendelijke groet / kind regards,
Mike Looijmans System Expert
TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijmans@topic.nl Website: www.topic.nl
Please consider the environment before printing this e-mail
Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/