Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <cover.1648714851.git.qinjian@cqplus1.com> <fe4f4c3b0c768d1cd66fb648d74fa302e86787c0.1648714851.git.qinjian@cqplus1.com>
 <CAK8P3a0OGM4aiaE2Nfc=7XGkGwAbnB99-j3PhVUmuA1z2FWeKg@mail.gmail.com> <2fa0ce6048f6449d883e2454ceea9540@cqplus1.com>
In-Reply-To: <2fa0ce6048f6449d883e2454ceea9540@cqplus1.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Fri, 1 Apr 2022 12:09:38 +0200
Message-ID: <CAK8P3a002iHquY4J59omBwxyZjCFFiymqbWKu9GXs-7RVy292g@mail.gmail.com>
Subject: Re: [PATCH v12 5/9] clk: Add Sunplus SP7021 clock driver
To:     =?UTF-8?B?cWluamlhblvopoPlgaVd?= <qinjian@cqplus1.com>
Cc:     Arnd Bergmann <arnd@arndb.de>,
        Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Marc Zyngier <maz@kernel.org>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        Russell King - ARM Linux <linux@armlinux.org.uk>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        DTML <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-clk <linux-clk@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Fri, Apr 1, 2022 at 11:47 AM qinjian[覃健] <qinjian@cqplus1.com> 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.
> >
>
> These code is refered from other clk driver.
> But, other driver need read then write, so need lock protected.
> Our  HW is HIWORD_MASKED_REG, means modify bits no need to read, just 1 write only.
> So, the lock is useless.
> Did I right?

If the read-modify-write is done on a different register, then it is
fine to remove
the lock. You can also consider having shadow registers to avoid expensive
r-m-w cycles and just always write the register directly.

> > > +       /* 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?
>
> I means, I must split up the origin reg region into 4 small pieces,
> and call devm_platform_ioremap_resource() 4 times.
> Did I should follow this way?

It depends. What are those other registers, and what drivers use them?

        Arnd