All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: "Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>,
	"Niklas Söderlund" <niso@kth.se>,
	"Koji Matsuoka" <koji.matsuoka.xm@rms.renesas.com>,
	"Magnus Damm" <damm@opensource.se>,
	"Nobuhiro Iwamatsu" <iwamatsu@nigauri.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	linux-sh@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [PATCH v2] pinctrl: sh-pfc: Improve pinmux macros documentation
Date: Wed, 25 Nov 2015 03:37:57 +0200	[thread overview]
Message-ID: <7920206.k8fTIRXnzu@avalon> (raw)
In-Reply-To: <1445368482-24278-1-git-send-email-geert+renesas@glider.be>

Hi Geert,

Thank you for the patch.

On Tuesday 20 October 2015 21:14:42 Geert Uytterhoeven wrote:
> Fix some s/ispr/ipsr/ typos in macro parameters while we're at it.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
>   - Clarify same width vs. different widths,
>   - Mention GPSR for PINMUX_IPSR_DATA(),
>   - Document NOGM (= NOGP + MSEL),
>   - Fix s/ispr/ipsr/ typos.
> ---
>  drivers/pinctrl/sh-pfc/sh_pfc.h | 84 ++++++++++++++++++++++++++++++++++++--
>  1 file changed, 81 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h
> b/drivers/pinctrl/sh-pfc/sh_pfc.h index 7b373d43d981899f..63e6cd050d0fb7d2
> 100644
> --- a/drivers/pinctrl/sh-pfc/sh_pfc.h
> +++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
> @@ -100,10 +100,31 @@ struct pinmux_cfg_reg {
>  	const u8 *var_field_width;
>  };
> 
> +/*
> + * Describe a config register consisting of several fields of the same
> width + *   - name: Register name (unused, for documentation purposes only)
> + *   - r: Physical register address
> + *   - r_width: Width of the register (in bits)
> + *   - f_width: Width of the fixed-width register fields (in bits)
> + * This macro must be followed by initialization data: For each register
> field + * (from left to right, i.e. MSB to LSB), 2^f_width enum IDs must be
> specified, + * one for each possible combination of the register field bit
> values. + */
>  #define PINMUX_CFG_REG(name, r, r_width, f_width) \
>  	.reg = r, .reg_width = r_width, .field_width = f_width,		\
>  	.enum_ids = (const u16 [(r_width / f_width) * (1 << f_width)])
> 
> +/*
> + * Describe a config register consisting of several fields of different
> widths + *   - name: Register name (unused, for documentation purposes
> only) + *   - r: Physical register address
> + *   - r_width: Width of the register (in bits)
> + *   - var_fw0, var_fwn...: List of widths of the register fields (in
> bits), + *                          From left to right (i.e. MSB to LSB)
> + * This macro must be followed by initialization data: For each register
> field + * (from left to right, i.e. MSB to LSB), 2^var_fwi enum IDs must be
> specified, + * one for each possible combination of the register field bit
> values. + */
>  #define PINMUX_CFG_REG_VAR(name, r, r_width, var_fw0, var_fwn...) \
>  	.reg = r, .reg_width = r_width,	\
>  	.var_field_width = (const u8 [r_width]) \
> @@ -116,6 +137,14 @@ struct pinmux_data_reg {
>  	const u16 *enum_ids;
>  };
> 
> +/*
> + * Describe a data register
> + *   - name: Register name (unused, for documentation purposes only)
> + *   - r: Physical register address
> + *   - r_width: Width of the register (in bits)
> + * This macro must be followed by initialization data: For each register
> bit + * (from left to right, i.e. MSB to LSB), one enum ID must be
> specified. + */
>  #define PINMUX_DATA_REG(name, r, r_width) \
>  	.reg = r, .reg_width = r_width,	\
>  	.enum_ids = (const u16 [r_width]) \
> @@ -124,6 +153,10 @@ struct pinmux_irq {
>  	const short *gpios;
>  };
> 
> +/*
> + * Describe the mapping from GPIOs to a single IRQ
> + *   - ids...: List of GPIOs that are mapped to the same IRQ
> + */
>  #define PINMUX_IRQ(ids...)			   \
>  	{ .gpios = (const short []) { ids, -1 } }
> 
> @@ -185,16 +218,61 @@ struct sh_pfc_soc_info {
>   * sh_pfc_soc_info pinmux_data array macros
>   */
> 
> +/*
> + * Describe generic pinmux data
> + *   - data_or_mark: *_DATA or *_MARK enum ID
> + *   - ids...: List of enum IDs to associate with data_or_mark
> + */
>  #define PINMUX_DATA(data_or_mark, ids...)	data_or_mark, ids, 0
> 
> -#define PINMUX_IPSR_NOGP(ispr, fn)					\
> +/*
> + * Describe a pinmux configuration without GPIO function that needs
> + * configuration in a Peripheral Function Select Register (IPSR)
> + *   - ipsr: IPSR field (unused, for documentation purposes only)
> + *   - fn: Function name
> + */
> +#define PINMUX_IPSR_NOGP(ipsr, fn)					\
>  	PINMUX_DATA(fn##_MARK, FN_##fn)

That's very confusing, as the ipsr argument is indeed unused, but the fn 
argument refers to a field value in an IPSR register. Could we fix that ? The 
same comment applies for other macros below.

> +
> +/*
> + * Describe a pinmux configuration with GPIO function that needs
> configuration
> + * in both a Peripheral Function Select Register (IPSR) and in a
> + * GPIO/Peripheral Function Select Register 1 (GPSR)
> + *   - ipsr: IPSR field
> + *   - fn: Function name
> + */
>  #define PINMUX_IPSR_DATA(ipsr, fn)					\
>  	PINMUX_DATA(fn##_MARK, FN_##fn, FN_##ipsr)

Should we rename this to PINMUX_IPSR_GPSR ?

> -#define PINMUX_IPSR_NOGM(ispr, fn, ms)					\
> +
> +/*
> + * Describe a pinmux configuration without GPIO function that needs
> + * configuration in a Peripheral Function Select Register (IPSR), and where
> the
> + * pinmux function has a representation in a configuration register.

I'd talk about module select register instead of configuration register. 
Configuration register is too vague.

> + *   - ipsr: IPSR field
> + *   - fn: Function name
> + *   - ms: Configuration register selector

I'd rename ms to msel to be more explicit.

> + */
> +#define PINMUX_IPSR_NOGM(ipsr, fn, ms)					\
>  	PINMUX_DATA(fn##_MARK, FN_##fn, FN_##ms)
> +
> +/*
> + * Describe a pinmux configuration where the pinmux function has no
> + * representation in the configuration registers but instead solely
> + * depends on a group selection.
> + *   - ipsr: IPSR field
> + *   - fn: Function name
> + *   - ms: Group selector
> + */
>  #define PINMUX_IPSR_NOFN(ipsr, fn, ms)					\
>  	PINMUX_DATA(fn##_MARK, FN_##ipsr, FN_##ms)

Those pins can be used as GPIO as well, right ? I think that should be 
mentioned.

The macro is used for emev2 only. It refers to a GPSR bit, not to an IPSR 
register. I think the ipsr argument should be renamed to reflect that.

> +
> +/*
> + * Describe a pinmux configuration where the pinmux function has a
> + * representation in a configuration register.

You mention "configuration register" here (and in the PINMUX_IPSR_NOGM 
description), while you talk about "group selector" for PINMUX_IPSR_NOFN. 
Aren't they the same ? 

> + *   - ipsr: IPSR field
> + *   - fn: Function name
> + *   - ms: Configuration register selector
> + */
>  #define PINMUX_IPSR_MSEL(ipsr, fn, ms)					\
>  	PINMUX_DATA(fn##_MARK, FN_##ms, FN_##ipsr, FN_##fn)
> 
> @@ -327,7 +405,7 @@ struct sh_pfc_soc_info {
>  	PINMUX_GPIO_FN(GPIO_FN_##str, PINMUX_FN_BASE, str##_MARK)
> 
>  /*
> - * PORTnCR macro
> + * PORTnCR helper macro for SH-Mobile/R-Mobile
>   */
>  #define PORTCR(nr, reg)							\
>  	{								\

As the comments I've made here have an air of déjà vu, I checked my review to 
v1 and realized you haven't replied to it. I don't think all the comments I 
made have been addressed in v2.

-- 
Regards,

Laurent Pinchart


WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: "Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>,
	"Niklas Söderlund" <niso@kth.se>,
	"Koji Matsuoka" <koji.matsuoka.xm@rms.renesas.com>,
	"Magnus Damm" <damm@opensource.se>,
	"Nobuhiro Iwamatsu" <iwamatsu@nigauri.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	linux-sh@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [PATCH v2] pinctrl: sh-pfc: Improve pinmux macros documentation
Date: Wed, 25 Nov 2015 01:37:57 +0000	[thread overview]
Message-ID: <7920206.k8fTIRXnzu@avalon> (raw)
In-Reply-To: <1445368482-24278-1-git-send-email-geert+renesas@glider.be>

Hi Geert,

Thank you for the patch.

On Tuesday 20 October 2015 21:14:42 Geert Uytterhoeven wrote:
> Fix some s/ispr/ipsr/ typos in macro parameters while we're at it.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
>   - Clarify same width vs. different widths,
>   - Mention GPSR for PINMUX_IPSR_DATA(),
>   - Document NOGM (= NOGP + MSEL),
>   - Fix s/ispr/ipsr/ typos.
> ---
>  drivers/pinctrl/sh-pfc/sh_pfc.h | 84 ++++++++++++++++++++++++++++++++++++--
>  1 file changed, 81 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h
> b/drivers/pinctrl/sh-pfc/sh_pfc.h index 7b373d43d981899f..63e6cd050d0fb7d2
> 100644
> --- a/drivers/pinctrl/sh-pfc/sh_pfc.h
> +++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
> @@ -100,10 +100,31 @@ struct pinmux_cfg_reg {
>  	const u8 *var_field_width;
>  };
> 
> +/*
> + * Describe a config register consisting of several fields of the same
> width + *   - name: Register name (unused, for documentation purposes only)
> + *   - r: Physical register address
> + *   - r_width: Width of the register (in bits)
> + *   - f_width: Width of the fixed-width register fields (in bits)
> + * This macro must be followed by initialization data: For each register
> field + * (from left to right, i.e. MSB to LSB), 2^f_width enum IDs must be
> specified, + * one for each possible combination of the register field bit
> values. + */
>  #define PINMUX_CFG_REG(name, r, r_width, f_width) \
>  	.reg = r, .reg_width = r_width, .field_width = f_width,		\
>  	.enum_ids = (const u16 [(r_width / f_width) * (1 << f_width)])
> 
> +/*
> + * Describe a config register consisting of several fields of different
> widths + *   - name: Register name (unused, for documentation purposes
> only) + *   - r: Physical register address
> + *   - r_width: Width of the register (in bits)
> + *   - var_fw0, var_fwn...: List of widths of the register fields (in
> bits), + *                          From left to right (i.e. MSB to LSB)
> + * This macro must be followed by initialization data: For each register
> field + * (from left to right, i.e. MSB to LSB), 2^var_fwi enum IDs must be
> specified, + * one for each possible combination of the register field bit
> values. + */
>  #define PINMUX_CFG_REG_VAR(name, r, r_width, var_fw0, var_fwn...) \
>  	.reg = r, .reg_width = r_width,	\
>  	.var_field_width = (const u8 [r_width]) \
> @@ -116,6 +137,14 @@ struct pinmux_data_reg {
>  	const u16 *enum_ids;
>  };
> 
> +/*
> + * Describe a data register
> + *   - name: Register name (unused, for documentation purposes only)
> + *   - r: Physical register address
> + *   - r_width: Width of the register (in bits)
> + * This macro must be followed by initialization data: For each register
> bit + * (from left to right, i.e. MSB to LSB), one enum ID must be
> specified. + */
>  #define PINMUX_DATA_REG(name, r, r_width) \
>  	.reg = r, .reg_width = r_width,	\
>  	.enum_ids = (const u16 [r_width]) \
> @@ -124,6 +153,10 @@ struct pinmux_irq {
>  	const short *gpios;
>  };
> 
> +/*
> + * Describe the mapping from GPIOs to a single IRQ
> + *   - ids...: List of GPIOs that are mapped to the same IRQ
> + */
>  #define PINMUX_IRQ(ids...)			   \
>  	{ .gpios = (const short []) { ids, -1 } }
> 
> @@ -185,16 +218,61 @@ struct sh_pfc_soc_info {
>   * sh_pfc_soc_info pinmux_data array macros
>   */
> 
> +/*
> + * Describe generic pinmux data
> + *   - data_or_mark: *_DATA or *_MARK enum ID
> + *   - ids...: List of enum IDs to associate with data_or_mark
> + */
>  #define PINMUX_DATA(data_or_mark, ids...)	data_or_mark, ids, 0
> 
> -#define PINMUX_IPSR_NOGP(ispr, fn)					\
> +/*
> + * Describe a pinmux configuration without GPIO function that needs
> + * configuration in a Peripheral Function Select Register (IPSR)
> + *   - ipsr: IPSR field (unused, for documentation purposes only)
> + *   - fn: Function name
> + */
> +#define PINMUX_IPSR_NOGP(ipsr, fn)					\
>  	PINMUX_DATA(fn##_MARK, FN_##fn)

That's very confusing, as the ipsr argument is indeed unused, but the fn 
argument refers to a field value in an IPSR register. Could we fix that ? The 
same comment applies for other macros below.

> +
> +/*
> + * Describe a pinmux configuration with GPIO function that needs
> configuration
> + * in both a Peripheral Function Select Register (IPSR) and in a
> + * GPIO/Peripheral Function Select Register 1 (GPSR)
> + *   - ipsr: IPSR field
> + *   - fn: Function name
> + */
>  #define PINMUX_IPSR_DATA(ipsr, fn)					\
>  	PINMUX_DATA(fn##_MARK, FN_##fn, FN_##ipsr)

Should we rename this to PINMUX_IPSR_GPSR ?

> -#define PINMUX_IPSR_NOGM(ispr, fn, ms)					\
> +
> +/*
> + * Describe a pinmux configuration without GPIO function that needs
> + * configuration in a Peripheral Function Select Register (IPSR), and where
> the
> + * pinmux function has a representation in a configuration register.

I'd talk about module select register instead of configuration register. 
Configuration register is too vague.

> + *   - ipsr: IPSR field
> + *   - fn: Function name
> + *   - ms: Configuration register selector

I'd rename ms to msel to be more explicit.

> + */
> +#define PINMUX_IPSR_NOGM(ipsr, fn, ms)					\
>  	PINMUX_DATA(fn##_MARK, FN_##fn, FN_##ms)
> +
> +/*
> + * Describe a pinmux configuration where the pinmux function has no
> + * representation in the configuration registers but instead solely
> + * depends on a group selection.
> + *   - ipsr: IPSR field
> + *   - fn: Function name
> + *   - ms: Group selector
> + */
>  #define PINMUX_IPSR_NOFN(ipsr, fn, ms)					\
>  	PINMUX_DATA(fn##_MARK, FN_##ipsr, FN_##ms)

Those pins can be used as GPIO as well, right ? I think that should be 
mentioned.

The macro is used for emev2 only. It refers to a GPSR bit, not to an IPSR 
register. I think the ipsr argument should be renamed to reflect that.

> +
> +/*
> + * Describe a pinmux configuration where the pinmux function has a
> + * representation in a configuration register.

You mention "configuration register" here (and in the PINMUX_IPSR_NOGM 
description), while you talk about "group selector" for PINMUX_IPSR_NOFN. 
Aren't they the same ? 

> + *   - ipsr: IPSR field
> + *   - fn: Function name
> + *   - ms: Configuration register selector
> + */
>  #define PINMUX_IPSR_MSEL(ipsr, fn, ms)					\
>  	PINMUX_DATA(fn##_MARK, FN_##ms, FN_##ipsr, FN_##fn)
> 
> @@ -327,7 +405,7 @@ struct sh_pfc_soc_info {
>  	PINMUX_GPIO_FN(GPIO_FN_##str, PINMUX_FN_BASE, str##_MARK)
> 
>  /*
> - * PORTnCR macro
> + * PORTnCR helper macro for SH-Mobile/R-Mobile
>   */
>  #define PORTCR(nr, reg)							\
>  	{								\

As the comments I've made here have an air of déjà vu, I checked my review to 
v1 and realized you haven't replied to it. I don't think all the comments I 
made have been addressed in v2.

-- 
Regards,

Laurent Pinchart


  parent reply	other threads:[~2015-11-25  1:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-20 19:14 [PATCH v2] pinctrl: sh-pfc: Improve pinmux macros documentation Geert Uytterhoeven
2015-10-20 19:14 ` Geert Uytterhoeven
2015-10-27 10:18 ` Linus Walleij
2015-10-27 10:18   ` Linus Walleij
2015-11-25  1:37 ` Laurent Pinchart [this message]
2015-11-25  1:37   ` Laurent Pinchart
2015-11-30 12:46   ` Geert Uytterhoeven
2015-11-30 12:46     ` Geert Uytterhoeven

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=7920206.k8fTIRXnzu@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=damm@opensource.se \
    --cc=geert+renesas@glider.be \
    --cc=iwamatsu@nigauri.org \
    --cc=koji.matsuoka.xm@rms.renesas.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=niso@kth.se \
    /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.