On Wed, Aug 14, 2013 at 02:19:37PM +0200, Sascha Hauer wrote:
Yes, since the clk names are not an API. Exposing them to the devicetree is not an option. The fact that the names are defined in arch/arm/mach-imx/clk-imx6q.c and are used in the spdif driver makes this really clear.
The spdif core has 8 input clocks which have to be described in the devicetree. Nobody says the mapping which clock name corresponds to which bit combination has to be in the devicetree.
Thank you for the explain. I get your point and really appreciate it.
Look at the possible clocks:
0000 if (DPLL Locked) SPDIF_RxClk else extal 0001 if (DPLL Locked) SPDIF_RxClk else spdif_clk 0010 if (DPLL Locked) SPDIF_RxClk else asrc_clk 0011 if (DPLL Locked) SPDIF_RxClk else spdif_extclk 0100 if (DPLL Locked) SPDIF_Rxclk else esai_hckt 0101 extal_clk 0110 spdif_clk 0111 asrc_clk 1000 spdif_extclk 1001 esai_hckt 1010 if (DPLL Locked) SPDIF_RxClk else mlb_clk 1011 if (DPLL Locked) SPDIF_RxClk else mlb_phy_clk 1100 mkb_clk 1101 mlb_phy_clk
Only half of them actually are clocks. "if (DPLL Locked) SPDIF_RxClk else ..." is not a clock. Every sane hardware developer would have introduced a mux with 8 entries and an additional "Use DPLL if possible" bit. Now this is not the case here so we have to live with it and maintain the above table in the driver. And another one for the i.MX35 and still another one for i.MX53.
I think I just have an idea for the table. I'll put them into the next version. Please take a look after I send it.
Thank you, Nicolin Chen