On Mon, Apr 28, 2014 at 10:13:55AM +0900, Simon Horman wrote: > On Mon, Apr 28, 2014 at 02:08:16AM +0200, Laurent Pinchart wrote: > > Hi Simon, > > > > On Monday 28 April 2014 09:03:14 Simon Horman wrote: > > > On Fri, Apr 25, 2014 at 09:11:06AM +0200, Geert Uytterhoeven wrote: > > > > On Fri, Apr 25, 2014 at 9:05 AM, Laurent Pinchart wrote: > > > > >> + scif0: serial@ffe40000 { > > > > >> + compatible = "renesas,scif", "renesas,scif-r8a7779"; > > > > >> + reg = <0xffe40000 265>; > > > > >> + interrupt-parent = <&gic>; > > > > >> + interrupts = <0 88 IRQ_TYPE_LEVEL_HIGH>; > > > > >> + clocks = <&cpg_clocks R8A7779_CLK_P>; > > > > >> + clock-names = "sci_ick"; > > > > > > > > > > Clock handling in the sh-sci driver should probably be improved. The > > > > > driver currently requires an "sci_ick" interface clock and supports an > > > > > optional "sci_fck" functional clock. In practice, as far as I can see, > > > > > platforms that provide both sci_ick and sci_fck set the two clocks to > > > > > the same source. > > > > > > > That's right. As a consequence, the clock's enable count is incremented > > > > > > > > 3 times: > > > > - once for fck, > > > > - once for ick, > > > > - once for generic Runtime PM using the "NULL" clock. > > > > > > This approach is fine by me. > > > But I think you need to maintain compatibility with the old > > > binding ("sci_ick" required, "sci_fsk") as it seems that > > > was included in v3.14. > > > > sci_fck isn't part of the DT bindings, so we can at least drop that one. > > So long as its not used anywhere in-tree, which I believe is the case, > then that is fine by me. BTW, are you planning to make the above mentioned driver update before or after re-posting enablement patches for Koelsch and/or Lager? I ask because I would like to make such patches the basis for a patch for Marzen. -- 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