On Monday 02 of December 2013 20:19:52 Rahul Sharma wrote: > Thanks Tomasz, > > On 2 December 2013 19:39, Tomasz Figa <t.figa@xxxxxxxxxxx> wrote: > > Hi Rahul, > > > > On Monday 02 of December 2013 11:25:16 Rahul Sharma wrote: > >> Samsung CCF helper functions doesn't provide support to > >> register multiple Clock Providers for a given SoC. Due to > >> this limitation soc platforms are not able to use these > >> helpers for registering multiple clock providers and forced > >> to bypass this layer. > > > > This might make sense indeed, but I don't see any use cases for it > > at the moment. Do you have anything in particular in mind? > > > > We had 2 clock providers (cmu and audss ) in 5420. In 5260, we had > 12 CMUs (top, egl, kfc, aud ...) which are physically independent and > mapped at non-contiguous phy-addresses. I am going to post the basic > patch set to add support for 5260 including clock file, which based on the > following RFC patch. OK, thanks for the explanation. So I guess support for the SoC itself is coming to the mainline too? > > > Also this is somehow ugly to require passing device_node to every function > > even when DT is not used. Instead, I would make samsung_clk_init() return > > the context pointer, which would be then passed to other functions. This > > would also eliminate the need to add private infrastructure mapping nodes > > into context pointers. > > > > yea correct. Sounds better. I will change it as you suggested. OK. > > > One more thing is the name of clk_provider_context struct. It sounds too > > generic for a Samsung specific structure. IMHO samsung_clk_provider would > > be much better. > > I named it simple as it is already defined in samsung/clk.c. > samsung_clk_provider > also seems good to me. OK. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |