linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Mark Brown <broonie@kernel.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
	Lee Jones <lee.jones@linaro.org>,
	Srinivas Ramana <sramana@codeaurora.org>,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/8] regmap: Add support for using regmap over ssbi
Date: Tue, 10 Dec 2013 17:32:51 -0800	[thread overview]
Message-ID: <52A7C0C3.2070805@codeaurora.org> (raw)
In-Reply-To: <20131211005106.GL11468@sirena.org.uk>

On 12/10/13 16:51, Mark Brown wrote:
> On Tue, Dec 10, 2013 at 04:13:15PM -0800, Stephen Boyd wrote:
>> increment reg by 1 every time through this loop. Or should we just have
>> use_single_rw == true?
> No, it doesn't - it increments the address of reg by the size of a
> register value each time.  Using use_single_rw might make sense, or if
> you can't do bulk I/O at all then hooking in via reg_read() and
> reg_write() in the config rather than trying to parse out the buffers
> might be even better (you can still make helpers to set that up).


Are you suggesting we implement the reg_read/reg_write as global helpers
that the config points to and then call regmap_init()? At a quick glance
it looks like we lose out on regmap_bulk_read() if we do that. There is
one driver that will use regmap_bulk_read(), but I suppose we can just
loop on regmap_read() and do our own increment? If we use use_single_rw
everything works and we can simplify this code to just pass the reg and
val buffers directly to ssbi_read/write.

This is what I have now.

static int regmap_ssbi_read(void *context,
                            const void *regp, size_t reg_size,
                            void *val, size_t val_size)
{
        int ret;
        u16 reg;

        BUG_ON(reg_size != 2);

        reg = *(u16 *)regp;
        while (val_size) {
                ret = ssbi_read(context, reg, val, 1);
                if (ret)
                        return ret;
                reg++;
                val += sizeof(u8);
                val_size -= sizeof(u8);
        }

        return 0;
}

With use_single_rw I think it can be this.

static int regmap_ssbi_read(void *context,
                            const void *reg, size_t reg_size,
                            void *val, size_t val_size)
{
        BUG_ON(reg_size != 2);  
        return ssbi_read(context, *(u16 *)reg, val, 1);
}

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2013-12-11  1:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-10 23:35 [PATCH 0/8] Modernize pm8921 with irqdomains + regmap Stephen Boyd
2013-12-10 23:35 ` [PATCH 1/8] mfd: ssbi: Remove platform data structs and hide ssbi type enum Stephen Boyd
2013-12-11  9:27   ` Lee Jones
2013-12-10 23:35 ` [PATCH 2/8] mfd: ssbi: Constify buffer in ssbi_write Stephen Boyd
2013-12-11  9:28   ` Lee Jones
2013-12-10 23:35 ` [PATCH 3/8] regmap: Add support for using regmap over ssbi Stephen Boyd
2013-12-10 23:50   ` Mark Brown
2013-12-11  0:13     ` Stephen Boyd
2013-12-11  0:51       ` Mark Brown
2013-12-11  1:32         ` Stephen Boyd [this message]
2013-12-11 13:27           ` Mark Brown
2013-12-12 23:13             ` Stephen Boyd
2013-12-13 10:41               ` Mark Brown
2013-12-13 17:14                 ` [PATCH] regmap: Allow regmap_bulk_read() to work for "no-bus" regmaps Stephen Boyd
2013-12-16 20:57                   ` Mark Brown
2013-12-13 21:37                 ` [PATCH 3/8] regmap: Add support for using regmap over ssbi Stephen Boyd
2013-12-16 21:01                   ` Mark Brown
2013-12-17  2:30                     ` [PATCH] regmap: Allow regmap_bulk_write() to work for "no-bus" regmaps Stephen Boyd
2013-12-18 18:45                       ` Mark Brown
2013-12-23 20:05                         ` Stephen Boyd
2013-12-24 12:53                           ` Mark Brown
2013-12-26 19:34                             ` Stephen Boyd
2013-12-26 21:52                               ` [PATCH v2] " Stephen Boyd
2013-12-30 12:42                                 ` Mark Brown
2013-12-10 23:35 ` [PATCH 4/8] mfd: ssbi: Mark match table const Stephen Boyd
2013-12-11  9:29   ` Lee Jones
2013-12-10 23:35 ` [PATCH 5/8] mfd: Move pm8xxx-irq.c contents into only driver that uses it Stephen Boyd
2013-12-11  9:35   ` Lee Jones
2013-12-12 19:06     ` Stephen Boyd
2013-12-10 23:35 ` [PATCH 6/8] mfd: pm8921: Update for genirq changes Stephen Boyd
2013-12-11  9:48   ` Lee Jones
2013-12-10 23:35 ` [PATCH 7/8] mfd: pm8921: Migrate to irqdomains Stephen Boyd
2013-12-11  9:53   ` Lee Jones
2013-12-11 21:30   ` Courtney Cavin
2013-12-12 19:05     ` Stephen Boyd
2013-12-10 23:35 ` [PATCH 8/8] mfd: pm8921: Use ssbi regmap Stephen Boyd
2013-12-11  9:55   ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52A7C0C3.2070805@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=broonie@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=sramana@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).