All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org, tiwai@suse.de, broonie@kernel.org,
	gregkh@linuxfoundation.org,
	Bard liao <yung-chuan.liao@linux.intel.com>,
	Rander Wang <rander.wang@linux.intel.com>,
	Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Sanyog Kale <sanyog.r.kale@intel.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] soundwire: SDCA: add helper macro to access controls
Date: Wed, 9 Sep 2020 13:25:55 +0530	[thread overview]
Message-ID: <20200909075555.GK77521@vkoul-mobl> (raw)
In-Reply-To: <f35a0ae7-2779-0c69-9ef3-0d0e298888ac@linux.intel.com>

On 08-09-20, 08:33, Pierre-Louis Bossart wrote:
> Thanks for the review Vinod,
> 
> > This is good, thanks for adding it in changelog. Can you also add this
> > description to Documentation (that can come as an individual patch),
> 
> ok
> 
> > > +/*
> > > + * v1.2 device - SDCA address mapping
> > > + *
> > > + * Spec definition
> > > + *	Bits		Contents
> > > + *	31		0 (required by addressing range)
> > > + *	30:26		0b10000 (Control Prefix)
> > 
> > So this is for 30:26
> 
> I don't get the comment, sorry.

I should have added see below.

> > 
> > > + *	25		0 (Reserved)
> > > + *	24:22		Function Number [2:0]
> > > + *	21		Entity[6]
> > > + *	20:19		Control Selector[5:4]
> > > + *	18		0 (Reserved)
> > > + *	17:15		Control Number[5:3]
> > > + *	14		Next
> > > + *	13		MBQ
> > > + *	12:7		Entity[5:0]
> > > + *	6:3		Control Selector[3:0]
> > > + *	2:0		Control Number[2:0]
> > > + */
> > > +
> > > +#define SDW_SDCA_CTL(fun, ent, ctl, ch)						\
> > > +	(BIT(30)							|	\
> > 
> > Programmatically this is fine, but then since we are defining for the
> > description above, IMO it would actually make sense for this to be defined
> > as FIELD_PREP:
> > 
> >          FIELD_PREP(GENMASK(30, 26), 1)
> > 
> > or better
> > 
> >          u32_encode_bits(GENMASK(30, 26), 1)
> > 
> > > +	FIELD_PREP(GENMASK(24, 22), FIELD_GET(GENMASK(2, 0), (fun)))	|	\
> > 
> > Why not use u32_encode_bits(GENMASK(24, 22), (fun)) instead for this and
> > below?
> 
> Because your comment for the v1 review was to use FIELD_PREP/FIELD_GET, and
> your other patches for bitfield access only use FIELD_PREP/FIELD_GET.

yes and looking at this, I feel u32_encode_bits(GENMASK(24, 22), (fun))
would look better than FIELD_PREP(GENMASK(24, 22), FIELD_GET(GENMASK(2, 0), (fun)))

Do you agree?

> 
> I really don't care about which macro is used but it wouldn't hurt to have
> some level of consistency between different parts of the code? Why not use
> FIELD_PREP/GET everywhere?
> 
> > > +	FIELD_PREP(BIT(21), FIELD_GET(BIT(6), (ent)))			|	\
> > > +	FIELD_PREP(GENMASK(20, 19), FIELD_GET(GENMASK(5, 4), (ctl)))	|	\
> > > +	FIELD_PREP(GENMASK(17, 15), FIELD_GET(GENMASK(5, 3), (ch)))	|	\
> > > +	FIELD_PREP(GENMASK(12, 7), FIELD_GET(GENMASK(5, 0), (ent)))	|	\
> > > +	FIELD_PREP(GENMASK(6, 3), FIELD_GET(GENMASK(3, 0), (ctl)))	|	\
> > > +	FIELD_PREP(GENMASK(2, 0), FIELD_GET(GENMASK(2, 0), (ch))))
> > 
> > Also, can we rather have a nice function for this, that would look much
> > cleaner
> 
> I am not sure what would be cleaner but fine.

Ok

> > And while at it, consider defining masks for various fields rather than
> > using numbers in GENMASK() above, that would look better, be more
> > readable and people can reuse it.
> 
> Actually on this one I disagree. These fields are not intended to be used by
> anyone, the goal is precisely to hide them behind regmap, and the use of raw
> numbers makes it easier to cross-check the documentation and the code.
> Adding a separate set of definitions would not increase readability.

Which one would you prefer:

        #define SDCA_FUN_MASK           GENMASK(24, 22)

        foo |= u32_encode_bits(SDCA_FUN_MASK, fun)

Or the one proposed...?

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>,
	alsa-devel@alsa-project.org,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	tiwai@suse.de, gregkh@linuxfoundation.org,
	open list <linux-kernel@vger.kernel.org>,
	broonie@kernel.org, Sanyog Kale <sanyog.r.kale@intel.com>,
	Bard liao <yung-chuan.liao@linux.intel.com>,
	Rander Wang <rander.wang@linux.intel.com>
Subject: Re: [PATCH v2 2/3] soundwire: SDCA: add helper macro to access controls
Date: Wed, 9 Sep 2020 13:25:55 +0530	[thread overview]
Message-ID: <20200909075555.GK77521@vkoul-mobl> (raw)
In-Reply-To: <f35a0ae7-2779-0c69-9ef3-0d0e298888ac@linux.intel.com>

On 08-09-20, 08:33, Pierre-Louis Bossart wrote:
> Thanks for the review Vinod,
> 
> > This is good, thanks for adding it in changelog. Can you also add this
> > description to Documentation (that can come as an individual patch),
> 
> ok
> 
> > > +/*
> > > + * v1.2 device - SDCA address mapping
> > > + *
> > > + * Spec definition
> > > + *	Bits		Contents
> > > + *	31		0 (required by addressing range)
> > > + *	30:26		0b10000 (Control Prefix)
> > 
> > So this is for 30:26
> 
> I don't get the comment, sorry.

I should have added see below.

> > 
> > > + *	25		0 (Reserved)
> > > + *	24:22		Function Number [2:0]
> > > + *	21		Entity[6]
> > > + *	20:19		Control Selector[5:4]
> > > + *	18		0 (Reserved)
> > > + *	17:15		Control Number[5:3]
> > > + *	14		Next
> > > + *	13		MBQ
> > > + *	12:7		Entity[5:0]
> > > + *	6:3		Control Selector[3:0]
> > > + *	2:0		Control Number[2:0]
> > > + */
> > > +
> > > +#define SDW_SDCA_CTL(fun, ent, ctl, ch)						\
> > > +	(BIT(30)							|	\
> > 
> > Programmatically this is fine, but then since we are defining for the
> > description above, IMO it would actually make sense for this to be defined
> > as FIELD_PREP:
> > 
> >          FIELD_PREP(GENMASK(30, 26), 1)
> > 
> > or better
> > 
> >          u32_encode_bits(GENMASK(30, 26), 1)
> > 
> > > +	FIELD_PREP(GENMASK(24, 22), FIELD_GET(GENMASK(2, 0), (fun)))	|	\
> > 
> > Why not use u32_encode_bits(GENMASK(24, 22), (fun)) instead for this and
> > below?
> 
> Because your comment for the v1 review was to use FIELD_PREP/FIELD_GET, and
> your other patches for bitfield access only use FIELD_PREP/FIELD_GET.

yes and looking at this, I feel u32_encode_bits(GENMASK(24, 22), (fun))
would look better than FIELD_PREP(GENMASK(24, 22), FIELD_GET(GENMASK(2, 0), (fun)))

Do you agree?

> 
> I really don't care about which macro is used but it wouldn't hurt to have
> some level of consistency between different parts of the code? Why not use
> FIELD_PREP/GET everywhere?
> 
> > > +	FIELD_PREP(BIT(21), FIELD_GET(BIT(6), (ent)))			|	\
> > > +	FIELD_PREP(GENMASK(20, 19), FIELD_GET(GENMASK(5, 4), (ctl)))	|	\
> > > +	FIELD_PREP(GENMASK(17, 15), FIELD_GET(GENMASK(5, 3), (ch)))	|	\
> > > +	FIELD_PREP(GENMASK(12, 7), FIELD_GET(GENMASK(5, 0), (ent)))	|	\
> > > +	FIELD_PREP(GENMASK(6, 3), FIELD_GET(GENMASK(3, 0), (ctl)))	|	\
> > > +	FIELD_PREP(GENMASK(2, 0), FIELD_GET(GENMASK(2, 0), (ch))))
> > 
> > Also, can we rather have a nice function for this, that would look much
> > cleaner
> 
> I am not sure what would be cleaner but fine.

Ok

> > And while at it, consider defining masks for various fields rather than
> > using numbers in GENMASK() above, that would look better, be more
> > readable and people can reuse it.
> 
> Actually on this one I disagree. These fields are not intended to be used by
> anyone, the goal is precisely to hide them behind regmap, and the use of raw
> numbers makes it easier to cross-check the documentation and the code.
> Adding a separate set of definitions would not increase readability.

Which one would you prefer:

        #define SDCA_FUN_MASK           GENMASK(24, 22)

        foo |= u32_encode_bits(SDCA_FUN_MASK, fun)

Or the one proposed...?

-- 
~Vinod

  reply	other threads:[~2020-09-09  7:56 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-01 16:22 [PATCH v2 0/3] regmap: add SoundWire 1.2 MBQ support Pierre-Louis Bossart
2020-09-01 16:22 ` [PATCH v2 1/3] regmap: sdw: add required header files Pierre-Louis Bossart
2020-09-01 16:22   ` Pierre-Louis Bossart
2020-09-01 16:22 ` [PATCH v2 2/3] soundwire: SDCA: add helper macro to access controls Pierre-Louis Bossart
2020-09-01 16:22   ` Pierre-Louis Bossart
2020-09-04  5:02   ` Vinod Koul
2020-09-04  5:02     ` Vinod Koul
2020-09-08 13:33     ` Pierre-Louis Bossart
2020-09-08 13:33       ` Pierre-Louis Bossart
2020-09-09  7:55       ` Vinod Koul [this message]
2020-09-09  7:55         ` Vinod Koul
2020-09-09 13:48         ` Pierre-Louis Bossart
2020-09-10  6:22           ` Vinod Koul
2020-09-10  6:22             ` Vinod Koul
2020-09-10 13:53             ` Pierre-Louis Bossart
2020-09-11  7:06               ` Vinod Koul
2020-09-11  7:06                 ` Vinod Koul
2020-09-11 14:50                 ` Pierre-Louis Bossart
2020-09-11 14:50                   ` Pierre-Louis Bossart
2020-09-14  5:08                   ` Vinod Koul
2020-09-14  5:08                     ` Vinod Koul
2020-09-14 14:44                     ` Pierre-Louis Bossart
2020-09-14 14:44                       ` Pierre-Louis Bossart
2020-09-16 12:35                       ` Vinod Koul
2020-09-16 12:35                         ` Vinod Koul
2020-09-16 13:11                         ` Pierre-Louis Bossart
2020-09-01 16:22 ` [PATCH v2 3/3] regmap: sdw: add support for SoundWire 1.2 MBQ Pierre-Louis Bossart
2020-09-01 16:22   ` Pierre-Louis Bossart
2020-09-03 10:36 ` [PATCH v2 0/3] regmap: add SoundWire 1.2 MBQ support Vinod Koul
2020-09-03 13:51   ` 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=20200909075555.GK77521@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=guennadi.liakhovetski@linux.intel.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=rander.wang@linux.intel.com \
    --cc=sanyog.r.kale@intel.com \
    --cc=tiwai@suse.de \
    --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.