All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: linux-sunxi@googlegroups.com, Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>, Chen-Yu Tsai <wens@csie.org>,
	alsa-devel@alsa-project.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6] sun4i-codec: Add FM, Line and Mic inputs
Date: Wed, 16 Dec 2015 11:47:36 +0100	[thread overview]
Message-ID: <20151216104736.GT19456@lukather> (raw)
In-Reply-To: <20151215025208.7c468673@dayas>

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

Hi,

On Tue, Dec 15, 2015 at 02:52:08AM +0100, Danny Milosavljevic wrote:
> Hi Maxime,
> 
> On Sun, 13 Dec 2015 21:58:39 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> 
> > This is not the branch you should be basing your patch on. This is an
> > ASoC patch, base it on the ASoC tree.
> 
> Okay, will do. To the branch "sunxi-next" in 
> <git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git>, right?
> 
> [...]
> > > -static const struct regmap_config sun4i_codec_regmap_config = {
> > > -	.reg_bits	= 32,
> > > -	.reg_stride	= 4,
> > > -	.val_bits	= 32,
> > > -	.max_register	= SUN4I_CODEC_AC_MIC_PHONE_CAL,
> > > -};
> > > -
> > 
> > Why is this moved?
> 
> Because SUN4I_CODEC_AC_MIC_PHONE_CAL is sun7i-specific.

Yet, you're using it in both cases (A10 vs A20).

> Note: I also renamed it and moved the #define in the course of grouping 
> together sun7i-specific things:
> 
> > +/* sun7i-specific things: */
> > +/* MIC_PHONE_CAL register offsets and bit fields (A20 only) */
> > +#define SUN7I_CODEC_AC_MIC_PHONE_CAL		(0x3c)
> [...]
> > +static const struct regmap_config sun4i_codec_regmap_config = {
> > +	.reg_bits	= 32,
> > +	.reg_stride	= 4,
> > +	.val_bits	= 32,
> > +	.max_register	= SUN7I_CODEC_AC_MIC_PHONE_CAL,
> > +};
> > +/* end sun7i-specific things */
> 
> I thought about also renaming sun4i_codec_regmap_config but decided against it 
> since it's fine to use it on A10 and I think it's best if the name reflects 
> the minimum required hardware.
> 
> On the other hand, once I moved the define, sun4i-codec won't compile if 
> sun4i_codec_regmap_config is left at the top. So I had to move it, too.

You can also have the defines on top, and everything just works :)

> It will be clearer once I post a patch doing just the preparation of the 
> A10/A20 split.
> 
> I just checked A10 vs A20 some more:
> There's also SUN4I_CODEC_AC_SYS_VERI 0x38 present in original ASoC and in 4.4-rc2.
> It's unused by us, not mentioned in the A10 User manual V1.5 20130820, and called 
> "AC_DAC_CAL" in the A20 User Manual v1.4 20150510. Ok to delete? 
> Or is it better to rename it to "SUN7I_CODEC_AC_DAC_CAL" rather than delete?

You can rename it if you want, but it's not like it's of the highest
importance :)

> 
> > >  static int sun4i_codec_probe(struct platform_device *pdev)
> > >  {
> > >  	struct snd_soc_card *card;
> > > @@ -593,6 +740,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
> > >  	struct resource *res;
> > >  	void __iomem *base;
> > >  	int ret;
> > > +	const struct snd_soc_codec_driver* codec_codec;
> > 
> > I guess a single codec is enough :)
> 
> Modeled after the name of the original variable, see below :)
> 
> But OK, I'll rename it to "codec".
> 
> Note: the newest original ASoC sun4i-codec has a variable
>   "struct sun4i_codec *scodec;"
> as well in the same function (which is a different thing).

I don't know what you're refering to with "newest" and "original".

But two different variables with two different names doesn't seem so
bad, does it?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Danny Milosavljevic <dannym-bxPqe3T81XXwRsdMLXbzog@public.gmane.org>
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
	Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Jaroslav Kysela <perex-/Fr2/VpizcU@public.gmane.org>,
	Takashi Iwai <tiwai-IBi9RG/b67k@public.gmane.org>,
	Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v6] sun4i-codec: Add FM, Line and Mic inputs
Date: Wed, 16 Dec 2015 11:47:36 +0100	[thread overview]
Message-ID: <20151216104736.GT19456@lukather> (raw)
In-Reply-To: <20151215025208.7c468673@dayas>

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

Hi,

On Tue, Dec 15, 2015 at 02:52:08AM +0100, Danny Milosavljevic wrote:
> Hi Maxime,
> 
> On Sun, 13 Dec 2015 21:58:39 +0100
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> 
> > This is not the branch you should be basing your patch on. This is an
> > ASoC patch, base it on the ASoC tree.
> 
> Okay, will do. To the branch "sunxi-next" in 
> <git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git>, right?
> 
> [...]
> > > -static const struct regmap_config sun4i_codec_regmap_config = {
> > > -	.reg_bits	= 32,
> > > -	.reg_stride	= 4,
> > > -	.val_bits	= 32,
> > > -	.max_register	= SUN4I_CODEC_AC_MIC_PHONE_CAL,
> > > -};
> > > -
> > 
> > Why is this moved?
> 
> Because SUN4I_CODEC_AC_MIC_PHONE_CAL is sun7i-specific.

Yet, you're using it in both cases (A10 vs A20).

> Note: I also renamed it and moved the #define in the course of grouping 
> together sun7i-specific things:
> 
> > +/* sun7i-specific things: */
> > +/* MIC_PHONE_CAL register offsets and bit fields (A20 only) */
> > +#define SUN7I_CODEC_AC_MIC_PHONE_CAL		(0x3c)
> [...]
> > +static const struct regmap_config sun4i_codec_regmap_config = {
> > +	.reg_bits	= 32,
> > +	.reg_stride	= 4,
> > +	.val_bits	= 32,
> > +	.max_register	= SUN7I_CODEC_AC_MIC_PHONE_CAL,
> > +};
> > +/* end sun7i-specific things */
> 
> I thought about also renaming sun4i_codec_regmap_config but decided against it 
> since it's fine to use it on A10 and I think it's best if the name reflects 
> the minimum required hardware.
> 
> On the other hand, once I moved the define, sun4i-codec won't compile if 
> sun4i_codec_regmap_config is left at the top. So I had to move it, too.

You can also have the defines on top, and everything just works :)

> It will be clearer once I post a patch doing just the preparation of the 
> A10/A20 split.
> 
> I just checked A10 vs A20 some more:
> There's also SUN4I_CODEC_AC_SYS_VERI 0x38 present in original ASoC and in 4.4-rc2.
> It's unused by us, not mentioned in the A10 User manual V1.5 20130820, and called 
> "AC_DAC_CAL" in the A20 User Manual v1.4 20150510. Ok to delete? 
> Or is it better to rename it to "SUN7I_CODEC_AC_DAC_CAL" rather than delete?

You can rename it if you want, but it's not like it's of the highest
importance :)

> 
> > >  static int sun4i_codec_probe(struct platform_device *pdev)
> > >  {
> > >  	struct snd_soc_card *card;
> > > @@ -593,6 +740,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
> > >  	struct resource *res;
> > >  	void __iomem *base;
> > >  	int ret;
> > > +	const struct snd_soc_codec_driver* codec_codec;
> > 
> > I guess a single codec is enough :)
> 
> Modeled after the name of the original variable, see below :)
> 
> But OK, I'll rename it to "codec".
> 
> Note: the newest original ASoC sun4i-codec has a variable
>   "struct sun4i_codec *scodec;"
> as well in the same function (which is a different thing).

I don't know what you're refering to with "newest" and "original".

But two different variables with two different names doesn't seem so
bad, does it?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6] sun4i-codec: Add FM, Line and Mic inputs
Date: Wed, 16 Dec 2015 11:47:36 +0100	[thread overview]
Message-ID: <20151216104736.GT19456@lukather> (raw)
In-Reply-To: <20151215025208.7c468673@dayas>

Hi,

On Tue, Dec 15, 2015 at 02:52:08AM +0100, Danny Milosavljevic wrote:
> Hi Maxime,
> 
> On Sun, 13 Dec 2015 21:58:39 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> 
> > This is not the branch you should be basing your patch on. This is an
> > ASoC patch, base it on the ASoC tree.
> 
> Okay, will do. To the branch "sunxi-next" in 
> <git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git>, right?
> 
> [...]
> > > -static const struct regmap_config sun4i_codec_regmap_config = {
> > > -	.reg_bits	= 32,
> > > -	.reg_stride	= 4,
> > > -	.val_bits	= 32,
> > > -	.max_register	= SUN4I_CODEC_AC_MIC_PHONE_CAL,
> > > -};
> > > -
> > 
> > Why is this moved?
> 
> Because SUN4I_CODEC_AC_MIC_PHONE_CAL is sun7i-specific.

Yet, you're using it in both cases (A10 vs A20).

> Note: I also renamed it and moved the #define in the course of grouping 
> together sun7i-specific things:
> 
> > +/* sun7i-specific things: */
> > +/* MIC_PHONE_CAL register offsets and bit fields (A20 only) */
> > +#define SUN7I_CODEC_AC_MIC_PHONE_CAL		(0x3c)
> [...]
> > +static const struct regmap_config sun4i_codec_regmap_config = {
> > +	.reg_bits	= 32,
> > +	.reg_stride	= 4,
> > +	.val_bits	= 32,
> > +	.max_register	= SUN7I_CODEC_AC_MIC_PHONE_CAL,
> > +};
> > +/* end sun7i-specific things */
> 
> I thought about also renaming sun4i_codec_regmap_config but decided against it 
> since it's fine to use it on A10 and I think it's best if the name reflects 
> the minimum required hardware.
> 
> On the other hand, once I moved the define, sun4i-codec won't compile if 
> sun4i_codec_regmap_config is left at the top. So I had to move it, too.

You can also have the defines on top, and everything just works :)

> It will be clearer once I post a patch doing just the preparation of the 
> A10/A20 split.
> 
> I just checked A10 vs A20 some more:
> There's also SUN4I_CODEC_AC_SYS_VERI 0x38 present in original ASoC and in 4.4-rc2.
> It's unused by us, not mentioned in the A10 User manual V1.5 20130820, and called 
> "AC_DAC_CAL" in the A20 User Manual v1.4 20150510. Ok to delete? 
> Or is it better to rename it to "SUN7I_CODEC_AC_DAC_CAL" rather than delete?

You can rename it if you want, but it's not like it's of the highest
importance :)

> 
> > >  static int sun4i_codec_probe(struct platform_device *pdev)
> > >  {
> > >  	struct snd_soc_card *card;
> > > @@ -593,6 +740,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
> > >  	struct resource *res;
> > >  	void __iomem *base;
> > >  	int ret;
> > > +	const struct snd_soc_codec_driver* codec_codec;
> > 
> > I guess a single codec is enough :)
> 
> Modeled after the name of the original variable, see below :)
> 
> But OK, I'll rename it to "codec".
> 
> Note: the newest original ASoC sun4i-codec has a variable
>   "struct sun4i_codec *scodec;"
> as well in the same function (which is a different thing).

I don't know what you're refering to with "newest" and "original".

But two different variables with two different names doesn't seem so
bad, does it?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151216/fef6d6db/attachment.sig>

  reply	other threads:[~2015-12-16 10:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09 22:55 [PATCH v6] sun4i-codec: Add FM, Line and Mic inputs Danny Milosavljevic
2015-12-09 22:55 ` Danny Milosavljevic
2015-12-09 22:55 ` Danny Milosavljevic
2015-12-13 20:58 ` Maxime Ripard
2015-12-13 20:58   ` Maxime Ripard
2015-12-13 20:58   ` Maxime Ripard
2015-12-15  1:52   ` Danny Milosavljevic
2015-12-15  1:52     ` Danny Milosavljevic
2015-12-15  1:52     ` Danny Milosavljevic
2015-12-16 10:47     ` Maxime Ripard [this message]
2015-12-16 10:47       ` Maxime Ripard
2015-12-16 10:47       ` Maxime Ripard
2015-12-16 22:30       ` [linux-sunxi] " Danny Milosavljevic
2015-12-16 22:30         ` Danny Milosavljevic
2015-12-16 22:30         ` Danny Milosavljevic
2015-12-18 10:19         ` [linux-sunxi] " Maxime Ripard
2015-12-18 10:19           ` Maxime Ripard
2015-12-18 10:19           ` Maxime Ripard
2015-12-21 18:41           ` [linux-sunxi] " Danny Milosavljevic
2015-12-21 18:41             ` Danny Milosavljevic
2015-12-21 18:41             ` Danny Milosavljevic

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=20151216104736.GT19456@lukather \
    --to=maxime.ripard@free-electrons.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=dannym@scratchpost.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    --cc=wens@csie.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.