All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-sound@vger.kernel.org, alsa-devel@alsa-project.org,
	tiwai@suse.de, vinod.koul@intel.com,
	Bard liao <yung-chuan.liao@linux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	srinivas.kandagatla@linaro.org,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	vijendar.mukunda@amd.com,
	Charles Keepax <ckeepax@opensource.cirrus.com>,
	Richard Fitzgerald <rf@opensource.cirrus.com>,
	Shuming Fan <shumingf@realtek.com>, Jack Yu <jack.yu@realtek.com>,
	Oder Chiou <oder_chiou@realtek.com>
Subject: Re: [RFC PATCH 01/16] Documentation: driver: add SoundWire BRA description
Date: Tue, 19 Dec 2023 17:50:30 +0100	[thread overview]
Message-ID: <700e564d-7e87-463a-a764-c4713ddf11cd@linux.intel.com> (raw)
In-Reply-To: <ZXOPWRWvrRddOWpT@finisterre.sirena.org.uk>



>>> This feels a lot like it could map onto the regmap async interface, it
>>> would need a bit of a rework (mainly that currently they provide
>>> ordering guarantees with respect to both each other and sync I/O) but
>>> those could be removed with some care) but it's got the "here's a list
>>> of I/O, here's another call to ensure it's all actually happened" thing.
>>> It sounds very much like how I was thinking of the async API when I was
>>> writing it and the initial users.
> 
>>> It's this bit that really got me thinking it could fit well into regmap.
> 
>> I really don't know anything about this async interface, if you have
>> pointers on existing examples I am all ears....I am not aware of any
>> Intel platform or codec used on an Intel platform making use of this API.
> 
> grep for regmap_.*async - cs_dsp.c is the upstream example in a driver,
> or there's the rbtree cache sync code which uses a back door to go into
> an async mode.  Basically just variants of all the normal regmap I/O
> calls with a _complete() call you can use to wait for everything to
> happen.  The implementation is a bit heavyweight since it was written to
> work with fairly slow buses.

I spent a fair amount of time this afternoon trying to understand the
regmap_async parts, and I am not following where in the code there is an
ordering requirement/enforcement between async and sync usages.

I do see this comment in the code

 * @async_write: Write operation which completes asynchronously,
optional and must serialise with respect to non-async I/O.

But that 'must' is a requirement on the codec side, isn't it?

When using regmap_raw_write_async(), the lock is released immediately. I
don't see anything at the regmap level that would prevent a codec driver
from using regmap_raw_write() immediately.

That's probably a violation of the API to do so, but it's the same
problem I was referring earlier in the conversation where 'regular'
read/writes cannot happen in parallel with BTP/BRA transactions.

Also is this just me spacing out or there is no regmap_raw_read_async()?


  reply	other threads:[~2023-12-19 16:51 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 22:29 [RFC PATCH 00/16] soundwire/ASoC: speed-up downloads with BTP/BRA protocol Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 01/16] Documentation: driver: add SoundWire BRA description Pierre-Louis Bossart
2023-12-07 23:29   ` Mark Brown
2023-12-08  0:56     ` Pierre-Louis Bossart
2023-12-08 21:49       ` Mark Brown
2023-12-19 16:50         ` Pierre-Louis Bossart [this message]
2023-12-19 16:53           ` Mark Brown
2023-12-19 17:08             ` Pierre-Louis Bossart
2023-12-20 15:16               ` Charles Keepax
2023-12-20 18:26                 ` Pierre-Louis Bossart
2023-12-20 18:28                   ` Mark Brown
2023-12-21  9:46                   ` Charles Keepax
2024-08-20  7:48     ` Pierre-Louis Bossart
2024-08-20 11:53       ` Mark Brown
2024-08-20 14:58         ` Pierre-Louis Bossart
2024-08-20 15:09           ` Mark Brown
2023-12-08 16:27   ` Charles Keepax
2023-12-08 18:45     ` Pierre-Louis Bossart
2023-12-08 18:55       ` Mark Brown
2023-12-18 11:40   ` Vinod Koul
2023-12-18 12:58     ` Pierre-Louis Bossart
2023-12-18 14:29       ` Charles Keepax
2023-12-18 16:33         ` Pierre-Louis Bossart
2023-12-21 14:45           ` Vinod Koul
2023-12-21 14:44         ` Vinod Koul
2023-12-21 14:44       ` Vinod Koul
2023-12-07 22:29 ` [RFC PATCH 02/16] soundwire: cadence: add BTP support for DP0 Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 03/16] soundwire: stream: extend sdw_alloc_stream() to take 'type' parameter Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 04/16] soundwire: extend sdw_stream_type to BPT Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 05/16] soundwire: stream: special-case the bus compute_params() routine Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 06/16] soundwire: stream: reuse existing code for BPT stream Pierre-Louis Bossart
2023-12-12 12:30   ` Charles Keepax
2023-12-18 10:45     ` Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 07/16] soundwire: bus: add API for BPT protocol Pierre-Louis Bossart
2023-12-12 12:19   ` Charles Keepax
2023-12-18 10:38     ` Pierre-Louis Bossart
2023-12-18 11:54   ` Vinod Koul
2023-12-18 13:12     ` Pierre-Louis Bossart
2023-12-18 14:57       ` Charles Keepax
2023-12-18 16:44         ` Pierre-Louis Bossart
2023-12-21 14:49       ` Vinod Koul
2023-12-07 22:29 ` [RFC PATCH 08/16] soundwire: bus: add bpt_stream pointer Pierre-Louis Bossart
2023-12-18 11:55   ` Vinod Koul
2023-12-18 13:20     ` Pierre-Louis Bossart
2023-12-21 14:39       ` Vinod Koul
2023-12-21 17:09         ` Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 09/16] soundwire: crc8: add constant table Pierre-Louis Bossart
2023-12-18 12:01   ` Vinod Koul
2023-12-18 13:26     ` Pierre-Louis Bossart
2023-12-21 14:42       ` Vinod Koul
2023-12-21 17:15         ` Pierre-Louis Bossart
2023-12-21 17:21           ` Vinod Koul
2023-12-07 22:29 ` [RFC PATCH 10/16] soundwire: cadence: add BTP/BRA helpers to format data Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 11/16] soundwire: intel_auxdevice: add indirection for BPT open/close/send_async/wait Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 12/16] ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMA Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 13/16] soundwire: intel: add BPT context definition Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 14/16] soundwire: intel_ace2x: add BPT open/close/send_async/wait Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 15/16] soundwire: debugfs: add interface for BPT/BRA transfers Pierre-Louis Bossart
2023-12-07 22:29 ` [RFC PATCH 16/16] ASoC: rt711-sdca: add DP0 support Pierre-Louis Bossart
2023-12-07 22:56 ` [RFC PATCH 00/16] soundwire/ASoC: speed-up downloads with BTP/BRA protocol Mark Brown
2023-12-07 23:06   ` Pierre-Louis Bossart

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=700e564d-7e87-463a-a764-c4713ddf11cd@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=jack.yu@realtek.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=oder_chiou@realtek.com \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=rf@opensource.cirrus.com \
    --cc=shumingf@realtek.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=tiwai@suse.de \
    --cc=vijendar.mukunda@amd.com \
    --cc=vinod.koul@intel.com \
    --cc=yung-chuan.liao@linux.intel.com \
    /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.