On Thu, May 31, 2018 at 10:31 AM, Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > Quoting Rob Herring (2018-05-31 07:20:57) >> On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu >> <codrin.ciubotariu@xxxxxxxxxxxxx> wrote: >> > On 31.05.2018 03:58, Rob Herring wrote: >> >> >> >> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote: >> >>> >> >>> The I2S mux clock can be used to select the I2S input clock. The >> >>> available parents are the peripheral and the generated clocks. >> >>> >> >>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@xxxxxxxxxxxxx> >> >>> --- >> >>> .../devicetree/bindings/clock/at91-clock.txt | 34 >> >>> ++++++++++++++++++++++ >> >>> 1 file changed, 34 insertions(+) >> >>> >> >>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt >> >>> b/Documentation/devicetree/bindings/clock/at91-clock.txt >> >>> index 51c259a..1c46b3c 100644 >> >>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt >> >>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt >> >>> @@ -90,6 +90,8 @@ Required properties: >> >>> "atmel,sama5d2-clk-audio-pll-pmc" >> >>> at91 audio pll output on AUDIOPLLCLK that feeds the PMC >> >>> and can be used by peripheral clock or generic clock >> >>> + "atmel,sama5d2-clk-i2s-mux": >> >>> + at91 I2S clock source selection >> >> >> >> >> >> Is this boolean or takes some values. If latter, what are valid values? >> > >> > >> > This is the compatible string of the clock driver. >> >> Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there >> still a plan to fix this? > > I'm also interested in a plan. > >> >> >> >>> + compatible = "atmel,sama5d2-clk-i2s-mux"; >> >>> + #address-cells = <1>; >> >>> + #size-cells = <0>; >> >> >> >> >> >> How do you address this block? My guess is you don't because it is just >> >> part of some other block and you are just creating this node to >> >> instantiate a driver. Just make the node for the actual h/w block a >> >> clock provider and define the clock ids (0 and 1). >> > >> > >> > This block is not addressed, but its children are. The register we access in >> > this driver is not part of other block. It's a SFR register, accessed >> > through syscon and it has nothing to do with the I2S IP (see SAMA5D2 DS, >> > page 1256, fig. 44-1: I2SC Block Diagram) that is the consumer of this >> > clock. Adding a clock-id property in the I2S node would be just like v3 of >> > this series, with the difference that we use clock-id instead of alias id to >> > set the clock parent, which is not how you suggested back then. >> >> I wasn't suggesting a clock-id property, but a clock specifier (i.e. >> make #clock-cells 1). >> >> But AT91 clocks are all a mess, so I don't know what to tell you. >> > > If #clock-cells of 1 works then we should go with that. It's still weird > that we need random nodes to add more clks, but I guess that's how it's > going to be for each at91 clk driver until it changes to be one big > provider node. Seems to me that clock additions could use a new binding and we start with a new driver that handles these few clocks initially. But I haven't looked whether both can coexist. Rob -- 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
