Quoting Sylwester Nawrocki (2018-12-05 02:57:32)
> On 12/4/18 19:40, Stephen Boyd wrote:
> > Quoting Kamil Konieczny (2018-12-04 08:52:48)
> >> +
> >> +static const unsigned long imem_clk_regs[] __initconst = {
> >> + ENABLE_ACLK_IMEM,
> >> + ENABLE_ACLK_IMEM_INT_MEM,
> >> + ENABLE_ACLK_IMEM_SSS,
> >> + ENABLE_ACLK_IMEM_SLIMSSS,
> >> + ENABLE_ACLK_IMEM_RTIC,
> >> + ENABLE_ACLK_IMEM_SMMU_SSS,
> >> + ENABLE_ACLK_IMEM_SMMU_SLIMSSS,
> >> + ENABLE_ACLK_IMEM_SMMU_RTIC,
> >> + ENABLE_ACLK_IMEM_ARBG_TX,
> >> + ENABLE_ACLK_IMEM_SMMU_ARBG_TX,
> >> + ENABLE_PCLK_IMEM,
> >> + ENABLE_PCLK_IMEM_SSS,
> >> + ENABLE_PCLK_IMEM_SLIMSSS,
> >> + ENABLE_PCLK_IMEM_RTIC,
> >> + ENABLE_PCLK_IMEM_SMMU_SSS,
> >> + ENABLE_PCLK_IMEM_SMMU_SLIMSSS,
> >> + ENABLE_PCLK_IMEM_SMMU_RTIC,
> >> + ENABLE_PCLK_IMEM_SMMU_ARGB_TX,
> >> +};
> >> +
> >> +static const struct samsung_gate_clock imem_gate_clks[] __initconst = {
> >> + /* ENABLE_ACLK_IMEM */
> >> + GATE(CLK_ACLK_AXI2AHB_IMEMH, "aclk_axi2ahb_imemh", "aclk_imem_200",
> >> + ENABLE_ACLK_IMEM, 24, 0, 0),
>
> I don't think that clock will ever need to be disabled/enabled, so I would
> drop this definition. The clock will remain in its default state after reset
> (enabled).
>
> >> + GATE(CLK_ACLK_AXIDS_SROMC, "aclk_axids_sromc", "aclk_imem_200",
> >> + ENABLE_ACLK_IMEM, 23, CLK_IGNORE_UNUSED, 0),
> >
> > Why is there so much use of CLK_IGNORE_UNUSED in this file?
>
> I suppose CLK_IGNORE_UNUSED is needed because there is no drivers that
> would enable required clocks. For some clocks the flag could probably
> indeed just be omitted, e.g. SLIMSSS clocks.
>
> I'm inclined to just define clocks that we are confident about and which
> are needed now. i.e. the SSS IP block clocks. So in include/dt-bindings/
> clock/exynos5433.h we would have something like:
Agreed, it doesn't make much sense to add clk support for clks that
you'll never need to modify one way or the other.
>
> +/* CMU_IMEM */
> +#define CLK_ACLK_SSS 1
> +#define CLK_PCLK_SSS 40
>
> +#define IMEM_NR_CLK 41
>
> The other clocks could be added later as needed by someone who has
> detailed knowledge about respective peripheral blocks.
>
The slow addition of new clks to the binding header file makes for an
integration problem, so can we try to expose any clks that we know about
now as defines and make them not work if the driver isn't implementing
support for those clks? That way the binding is not changing but the
implementation can decide to support or not support certain clks.
