On Thu, Mar 31, 2022 at 10:29 AM Qin Jian <qinjian@xxxxxxxxxxx> wrote:
> +static int sp_pll_enable(struct clk_hw *hw)
> +{
> + struct sp_pll *clk = to_sp_pll(hw);
> + unsigned long flags;
> +
> + spin_lock_irqsave(clk->lock, flags);
> + writel(BIT(clk->pd_bit + 16) | BIT(clk->pd_bit), clk->reg); /* power up */
> + spin_unlock_irqrestore(clk->lock, flags);
> +
> + return 0;
> +}
> +
> +static void sp_pll_disable(struct clk_hw *hw)
> +{
> + struct sp_pll *clk = to_sp_pll(hw);
> + unsigned long flags;
> +
> + spin_lock_irqsave(clk->lock, flags);
> + writel(BIT(clk->pd_bit + 16), clk->reg); /* power down */
> + spin_unlock_irqrestore(clk->lock, flags);
> +}
What does the spinlock actually protect here? As writel() is posted, it
can already leak of of the lock, and the inputs would appear to be
constant.
> + /* This memory region include multi HW regs in discontinuous order.
> + * clk driver used some discontinuous areas in the memory region.
> + * Using devm_platform_ioremap_resource() would conflicted with other drivers.
> + */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + sp_clk_base = devm_ioremap(dev, res->start, resource_size(res));
> + if (!sp_clk_base)
> + return -ENXIO;
Can you explain this comment in more detail? Generally, the 'reg' properties
of drivers should not overlap, so it is supposed to be safe to call
devm_platform_ioremap_resource() here.
We discussed this in the context of the iop driver that did have overlapping
registers with this driver, and that was incorrect. Are there any other drivers
that conflict with the clk driver?
Arnd
