All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Krystian Garbaciak <krystian.garbaciak@diasemi.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	Anthony Olech <Anthony.Olech@diasemi.com>
Subject: Re: [PATCH 2/4] regmap: Make internal read/write functions reentrant from themselves.
Date: Thu, 31 May 2012 17:40:33 +0100	[thread overview]
Message-ID: <20120531164033.GJ2666@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <201205311616.q4VGGZjR014516@sw-eng-lt-dc-vm2>

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

On Thu, May 31, 2012 at 04:19:36PM +0200, Krystian Garbaciak wrote:

> Functions _regmap_update_bits() and _regmap_write() are modified
> so they can be recurrently entered from the inside.

You should describe what you're doing here in more detail...

> The internal reading functions need no modification for current implementation
> of indirect access.

So the subject should really be "Make internal write functions
reentrant"?

> -		map->format.format_val(map->work_buf + map->format.reg_bytes
> -				       + map->format.pad_bytes, val);
> -		return _regmap_raw_write(map, reg,
> -					 map->work_buf +
> -					 map->format.reg_bytes +
> -					 map->format.pad_bytes,
> +		/* Using stack for value data, to make function reentrant */
> +		map->format.format_val(&val, val);
> +		return _regmap_raw_write(map, reg, &val,

We can't safely do this for all buses, some want to DMA and you can't
DMA from stack.  This also means that we'll no longer be able to send a
single buffer to the device as we'll never have the value immediately
following the register address and padding any more.  That'll increase
overhead on many systems, you can often see the handover on gathers on a
scope.

I don't understand why we can't take the decision to write the page
register before we start using the buffer?

Also, it seems like your mailing setup is a bit broken - these messages
aren't being threaded with each other.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-05-31 16:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-31 14:19 [PATCH 2/4] regmap: Make internal read/write functions reentrant from themselves Krystian Garbaciak
2012-05-31 16:40 ` Mark Brown [this message]
2012-05-31 17:49   ` Krystian Garbaciak

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=20120531164033.GJ2666@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=Anthony.Olech@diasemi.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=krystian.garbaciak@diasemi.com \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.