On Mon, Aug 19, 2013 at 10:54:33AM +0100, Mark Rutland wrote: > > I see, so 'Compatible list, must contains "fsl,imx35-spdif"' would be okay? > > While that needs to be mentioned, other values which might be present > (e.g. "fsl,imx6q-spdif") must be mentioned, or we can't rely on them > if we want to use them in future from drivers to provide additional > information (and thus they're useless). Well, imx6q-spdif is identical to the imx35-spdif. So I think the 'must contains 35' would be enough for the current case. If any future modification happens to the list, I can update this doc later. > > > > > > + - interrupts : Contains spdif interrupt. > > > > > > Is that the only interrupt the device generates? > > > > Yes, how could I improve this description? > > It's probably not possible to make it much clearar to be honest, > "Contains the sole interrupt generated by the device" might be a little > overkill. Then I keep it no-change :) > > > > + "rxtx<0-7>" Clock source list for tx and rx clock. > > > > + This clock list should be identical to > > > > + the source list connecting to the spdif > > > > + clock mux in "SPDIF Transceiver Clock > > > > + Diagram" of SoC reference manual. It > > > > + can also be referred to TxClk_Source > > > > + bit of register SPDIF_STC. > > The list is also identical to the TxClk_Source bit value list of > > register SPDIF_STC. > > What I don't understand is how the value of the SPDIF_STC register > within the spdif IP block can describe the necessary details of clocks > coming from an external clock provider. > > What do the TxClk_Source bits represent? The configuration of the clock > inputs on the spdif IP block, or the outputs on some clock provider? Are > they writeable, or configured at integration time? If the clock provider > were replaced with another arbitrary clock provider, what would they > represent? Actually there's a clock mux for TxClk and it's connecting with 8 clock sources. So the TxClk_Source bit show the connection between its value with the correspond source on the clock mux: TxClk_Source 000 XTAL clk input 001 CCM spdif0_clk_root input 010 asrc_clk input 011 spdif_extclk input, from pads 100 esai_hckt input 101 frequency divided ipg_clk input 110 mlb_clk input 111 mlb phy clk input > > I guess it's better to drop the 'imx6q-spdif' here? > > That depends: > > * If the two IP blocks are identical, only the "imx35-spdif" name is > necessary, and we can forget about "fsl,imx6q-spdif". > > * If "fsl,imx6q-spdif" is a strict superset of "fsl,imx35-spdif", having > both names documented and in a compatible list for a "fsl,imx6q-spdif" > device makes sense. > > * If "fsl,imx6q-spdif" is a variation of "fsl,imx35-spdif", and the > "fsl,imx6q-spdif" cannot always be treated identically to a > "fsl,imx35-spdif", then it makes sense to have separate compatible > strings, with a device being listed as either "fsl,imx6q-spdif" or > "fsl,imx35-spdif". > > I don't know enough about the hardware to make that judgement call. Thank you for explaining! I will choose A, because they are internally identical except their external clock sources. Best regards, Nicolin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
