On 25/01/2024 12:53, Théo Lebrun wrote: > Hi, > > On Thu Jan 25, 2024 at 8:46 AM CET, Krzysztof Kozlowski wrote: >> On 24/01/2024 17:41, Théo Lebrun wrote: >>> Hello, >>> >>> On Wed Jan 24, 2024 at 8:05 AM CET, Krzysztof Kozlowski wrote: >>>> On 23/01/2024 19:46, Théo Lebrun wrote: >>>>> Add the Mobileye EyeQ5 clock controller driver. It might grow to add >>>>> support for other platforms from Mobileye. >>>>> >>>>> It handles 10 read-only PLLs derived from the main crystal on board. It >>>>> exposes a table-based divider clock used for OSPI. Other platform >>>>> clocks are not configurable and therefore kept as fixed-factor >>>>> devicetree nodes. >>>>> >>>>> Two PLLs are required early on and are therefore registered at >>>>> of_clk_init(). Those are pll-cpu for the GIC timer and pll-per for the >>>>> UARTs. >>>>> >>>> >>>> >>>>> +#define OLB_PCSR1_RESET BIT(0) >>>>> +#define OLB_PCSR1_SSGC_DIV GENMASK(4, 1) >>>>> +/* Spread amplitude (% = 0.1 * SPREAD[4:0]) */ >>>>> +#define OLB_PCSR1_SPREAD GENMASK(9, 5) >>>>> +#define OLB_PCSR1_DIS_SSCG BIT(10) >>>>> +/* Down-spread or center-spread */ >>>>> +#define OLB_PCSR1_DOWN_SPREAD BIT(11) >>>>> +#define OLB_PCSR1_FRAC_IN GENMASK(31, 12) >>>>> + >>>>> +static struct clk_hw_onecell_data *eq5c_clk_data; >>>>> +static struct regmap *eq5c_olb; >>>> >>>> Drop these two. No file-scope regmaps for drivers. Use private container >>>> structures. >>> >>> I wouldn't know how to handle the two steps then. Two clocks and the clk >>> provider are registered at of_clk_init() using CLK_OF_DECLARE_DRIVER(). >> >> Right, if some clocks have to be early, CLK_OF_DECLARE_DRIVER needs >> static ones. But your commit subject says it is a platform driver and >> all other pieces of this code is rather incompatible with this approach. > > That is my bad on the commit subject. What do you refer to by "all other > pieces of this code is rather incompatible with this approach"? That you depend on syscon. If it was regular MMIO block in SoC space, then no problem. If you depend on anything else providing you regmap, then any initcall ordering is fragile and error-prone. Avoid. > > I've tried to minimise the use of static variables. Therefore as soon as > the probe is started, we switch to the usual way of using a private > struct that contains our info. > >> >> Do not use CLK_OF_DECLARE_DRIVER for cases where you have dependencies >> because it forces you to manually order initcalls, which is exactly what >> we do not want. > > What should I be using? I got confirmation from Stephen that this > mixture of CLK_OF_DECLARE_DRIVER() + platform driver is what I should > be using as review in my V1. > > https://lore.kernel.org/lkml/fa32e6fae168e10d42051b89197855e9.sboyd@xxxxxxxxxx/ I see. In such case I believe it is error on relying on syscon. Best regards, Krzysztof
