Re: [PATCH v11 1/4] firmware: qcom: scm: provide a read-modify-write function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2/17/2024 12:01 AM, Bjorn Andersson wrote:
On Tue, Jan 09, 2024 at 02:34:10PM +0100, Linus Walleij wrote:
On Tue, Jan 9, 2024 at 2:24 PM Mukesh Ojha <quic_mojha@xxxxxxxxxxx> wrote:
On 1/9/2024 6:44 PM, Linus Walleij wrote:
On Mon, Jan 8, 2024 at 4:28 PM Mukesh Ojha <quic_mojha@xxxxxxxxxxx> wrote:

It was realized by Srinivas K. that there is a need of
read-modify-write scm exported function so that it can
be used by multiple clients.

Let's introduce qcom_scm_io_rmw() which masks out the bits
and write the passed value to that bit-offset.
(...)
+int qcom_scm_io_rmw(phys_addr_t addr, unsigned int mask, unsigned int val)
+{
+       unsigned int old, new;
+       int ret;
+
+       if (!__scm)
+               return -EINVAL;
+
+       spin_lock(&__scm->lock);
+       ret = qcom_scm_io_readl(addr, &old);
+       if (ret)
+               goto unlock;
+
+       new = (old & ~mask) | (val & mask);
+
+       ret = qcom_scm_io_writel(addr, new);
+unlock:
+       spin_unlock(&__scm->lock);
+       return ret;
+}
+EXPORT_SYMBOL_GPL(qcom_scm_io_rmw);

This looks a lot like you are starting to re-invent regmaps
regmap_update_bits().

If you are starting to realize you need more and more of
regmap, why not use regmap and its functions?

I think, this discussion has happened already ..

https://lore.kernel.org/lkml/CACRpkdb95V5GC81w8fiuLfx_V1DtWYpO33FOfMnArpJeC9SDQA@xxxxxxxxxxxxxx/

That discussion ended with:

[Bjorn]
We'd still need qcom_scm_io_readl() and qcom_scm_io_writel() exported to
implement the new custom regmap implementation - and the struct
regmap_config needed in just pinctrl-msm alone would be larger than the
one function it replaces.

When you add more and more accessors the premise starts to
change, and it becomes more and more of a reimplementation.

It may be time to actually fix this.


Thought I had replied to this already, did we discuss this previously as
well?

My concern with expressing this as a regmap is that from the provider's
point of view, the regmap would span the entire 32-bit address space.
I'm guessing that there's something on the other side limiting what
subregions are actually accessible for each platform/firmware
configuration, but I'm not convinced that regmap a good abstraction...

To add more to it, in current series, we are just accessing single register for read/write and using regmap for this looks overkill to
me.

-Mukesh

Regards,
Bjorn

Yours,
Linus Walleij




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux