linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	tiwai@suse.de, vkoul@kernel.org, gregkh@linuxfoundation.org,
	jank@cadence.com, srinivas.kandagatla@linaro.org,
	slawomir.blauciak@intel.com,
	Bard liao <yung-chuan.liao@linux.intel.com>,
	Rander Wang <rander.wang@linux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Hui Wang <hui.wang@canonical.com>,
	Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH 4/4] regmap: sdw: add support for SoundWire 1.2 MBQ
Date: Wed, 26 Aug 2020 09:54:16 -0500	[thread overview]
Message-ID: <e66a9e95-7846-f353-8ebd-e35458c79797@linux.intel.com> (raw)
In-Reply-To: <20200826101637.GC4965@sirena.org.uk>



>> One possible objection is that this code could have been handled with
>> regmap-sdw.c. However this is a new spec addition not handled by every
>> SoundWire 1.1 and non-SDCA device, so there's no reason to load code
>> that will never be used.
> 
>> Also in practice it's extremely unlikely that CONFIG_REGMAP would not
>> be selected with CONFIG_REGMAP_MBQ selected. However there's no
>> functional dependency between the two modules so they can be selected
>> separately.
> 
> The other thing I'm wondering here is about compatibility - is this
> something we can enumerate at runtime and if so couldn't this be done
> more like how we handle the various I2C and SMBus variants so the driver
> just says it wants a SoundWire regmap and then based on the capabilities
> of the device and the controller the regmap decides if it can use MBQ or
> not on the current system?

An SDCA device will have two regmaps, one for 'regular' registers and 
one for MBQ-based ones. There is no known case where a codec can use 
ONLY an MBQ-based regmap.

It's different from I2C/SMB since the bus is really identical, the 
interface is the same, the difference is really the sequence by which 
you access registers allocated to SDCA and how the address is constructed.

Each SDCA control will be described with a firmware property, and based 
on their range and purpose you would know how if the control is a 
regular one or an MBQ-based one. Alternatively, the driver might 
hard-code things and define addresses for each.

Does this answer to your question?


      reply	other threads:[~2020-08-26 15:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-25 17:16 [PATCH 0/4] regmap: add SoundWire 1.2 MBQ support Pierre-Louis Bossart
2020-08-25 17:16 ` [PATCH 1/4] regmap: sdw: move to -EOPNOTSUPP Pierre-Louis Bossart
2020-08-25 21:48   ` Mark Brown
2020-08-25 22:08     ` Pierre-Louis Bossart
2020-08-26  9:56       ` Mark Brown
2020-08-26 10:09         ` Takashi Iwai
2020-08-26 10:13           ` Mark Brown
2020-08-26 10:22             ` Takashi Iwai
2020-08-26 12:03               ` Vinod Koul
2020-08-26 15:05               ` Pierre-Louis Bossart
2020-08-26 17:25                 ` Mark Brown
2020-08-26 18:08                   ` Pierre-Louis Bossart
2020-08-25 17:16 ` [PATCH 2/4] regmap: sdw: add required header files Pierre-Louis Bossart
2020-08-25 17:16 ` [PATCH 3/4] soundwire: SDCA: add helper macro to access controls Pierre-Louis Bossart
2020-08-26  1:04   ` Bard liao
2020-08-26  8:55   ` Vinod Koul
2020-08-26 15:00     ` Pierre-Louis Bossart
2020-08-26 16:40       ` Vinod Koul
2020-08-25 17:16 ` [PATCH 4/4] regmap: sdw: add support for SoundWire 1.2 MBQ Pierre-Louis Bossart
2020-08-26  0:59   ` Bard liao
2020-08-26  9:05   ` Vinod Koul
2020-08-26 16:57     ` Pierre-Louis Bossart
2020-08-28  7:23       ` Vinod Koul
2020-08-28 14:49         ` Pierre-Louis Bossart
2020-08-26 10:16   ` Mark Brown
2020-08-26 14:54     ` Pierre-Louis Bossart [this message]

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=e66a9e95-7846-f353-8ebd-e35458c79797@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=guennadi.liakhovetski@linux.intel.com \
    --cc=hui.wang@canonical.com \
    --cc=jank@cadence.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rander.wang@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=slawomir.blauciak@intel.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=tiwai@suse.de \
    --cc=vkoul@kernel.org \
    --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 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).