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: Re: [PATCH v6] sun4i-codec: Add FM, Line and Mic inputs
Date: Fri, 18 Dec 2015 11:19:43 +0100 [thread overview]
Message-ID: <20151218101943.GI30359@lukather> (raw)
In-Reply-To: <20151216233051.09d34738@dayas>
[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]
On Wed, Dec 16, 2015 at 11:30:51PM +0100, Danny Milosavljevic wrote:
> Hi Maxime,
>
> On Wed, 16 Dec 2015 11:47:36 +0100
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > > Because SUN4I_CODEC_AC_MIC_PHONE_CAL is sun7i-specific.
> >
> > Yet, you're using it in both cases (A10 vs A20).
>
> Yes. I'm trying to keep complexity and duplication down.
> I figured it wouldn't be bad to have unused registers in the regmap.
>
> (Technially .max_register = MAX(max_register_a10, max_register_a20) would be
> better. Should we do that?)
>
> If it's bad in this case, we have to split it up, but frankly the *codec_probe()
> function is much too long now and this would make it even longer.
>
> Also, it was that way before, so I'm mostly using it in both cases because
> previously it was also used in both cases (with the too-large max-register),
> apparently without problems.
>
> Should I duplicate and adapt the structure?
No, my point was that you don't need to move it around at all.
> > You can also have the defines on top, and everything just works :)
>
> The idea is to make the compiler complain when I try to use a sun7i define in a
> generic sun4i function (or struct, in this case) - because that would probably
> be causing problems at runtime, too. Better to catch problems earlier.
> So I kept the sun7i-specific things closely together and as much to the bottom
> of the file as possible - as a poor-mans modularity.
> If I kept the sun7i defines at the top I could use them anywhere with impunity -
> also in the A10 case - and it would not complain.
>
> But it's mostly to make the life of the developer easier, so feel free to choose
> otherwise. (not sarcasm)
I understand your point to develop it, but now, the development is done :)
Having all the defines packed together is easier to read and maintain
after the development is done.
> > > 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 :)
>
> The only somewhat important part of the name is the "7".
> If you use a "7"-register on an A10, it's not going to work at runtime, or worse:
> do something else that wasn't intended. Right now it has a "4" although it isn't
> an A10 register. This separation should be visible somewhere in the source code,
> or problems are going to slip through later.
>
> I agree it's not at all important right now because the register is unused
> by us :P
Exactly my point ;)
Like I said, if you want to rename it, go ahead. It would also be a
good idea to open a github issue on allwinner's documentation repo to
make them know that the register name doesn't match between the
register list and the register documentations.
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: [linux-sunxi] Re: [PATCH v6] sun4i-codec: Add FM, Line and Mic inputs
Date: Fri, 18 Dec 2015 11:19:43 +0100 [thread overview]
Message-ID: <20151218101943.GI30359@lukather> (raw)
In-Reply-To: <20151216233051.09d34738@dayas>
On Wed, Dec 16, 2015 at 11:30:51PM +0100, Danny Milosavljevic wrote:
> Hi Maxime,
>
> On Wed, 16 Dec 2015 11:47:36 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > > Because SUN4I_CODEC_AC_MIC_PHONE_CAL is sun7i-specific.
> >
> > Yet, you're using it in both cases (A10 vs A20).
>
> Yes. I'm trying to keep complexity and duplication down.
> I figured it wouldn't be bad to have unused registers in the regmap.
>
> (Technially .max_register = MAX(max_register_a10, max_register_a20) would be
> better. Should we do that?)
>
> If it's bad in this case, we have to split it up, but frankly the *codec_probe()
> function is much too long now and this would make it even longer.
>
> Also, it was that way before, so I'm mostly using it in both cases because
> previously it was also used in both cases (with the too-large max-register),
> apparently without problems.
>
> Should I duplicate and adapt the structure?
No, my point was that you don't need to move it around at all.
> > You can also have the defines on top, and everything just works :)
>
> The idea is to make the compiler complain when I try to use a sun7i define in a
> generic sun4i function (or struct, in this case) - because that would probably
> be causing problems at runtime, too. Better to catch problems earlier.
> So I kept the sun7i-specific things closely together and as much to the bottom
> of the file as possible - as a poor-mans modularity.
> If I kept the sun7i defines at the top I could use them anywhere with impunity -
> also in the A10 case - and it would not complain.
>
> But it's mostly to make the life of the developer easier, so feel free to choose
> otherwise. (not sarcasm)
I understand your point to develop it, but now, the development is done :)
Having all the defines packed together is easier to read and maintain
after the development is done.
> > > 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 :)
>
> The only somewhat important part of the name is the "7".
> If you use a "7"-register on an A10, it's not going to work at runtime, or worse:
> do something else that wasn't intended. Right now it has a "4" although it isn't
> an A10 register. This separation should be visible somewhere in the source code,
> or problems are going to slip through later.
>
> I agree it's not at all important right now because the register is unused
> by us :P
Exactly my point ;)
Like I said, if you want to rename it, go ahead. It would also be a
good idea to open a github issue on allwinner's documentation repo to
make them know that the register name doesn't match between the
register list and the register documentations.
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/20151218/e782bb2e/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
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: [linux-sunxi] Re: [PATCH v6] sun4i-codec: Add FM, Line and Mic inputs
Date: Fri, 18 Dec 2015 11:19:43 +0100 [thread overview]
Message-ID: <20151218101943.GI30359@lukather> (raw)
In-Reply-To: <20151216233051.09d34738@dayas>
[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]
On Wed, Dec 16, 2015 at 11:30:51PM +0100, Danny Milosavljevic wrote:
> Hi Maxime,
>
> On Wed, 16 Dec 2015 11:47:36 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > > Because SUN4I_CODEC_AC_MIC_PHONE_CAL is sun7i-specific.
> >
> > Yet, you're using it in both cases (A10 vs A20).
>
> Yes. I'm trying to keep complexity and duplication down.
> I figured it wouldn't be bad to have unused registers in the regmap.
>
> (Technially .max_register = MAX(max_register_a10, max_register_a20) would be
> better. Should we do that?)
>
> If it's bad in this case, we have to split it up, but frankly the *codec_probe()
> function is much too long now and this would make it even longer.
>
> Also, it was that way before, so I'm mostly using it in both cases because
> previously it was also used in both cases (with the too-large max-register),
> apparently without problems.
>
> Should I duplicate and adapt the structure?
No, my point was that you don't need to move it around at all.
> > You can also have the defines on top, and everything just works :)
>
> The idea is to make the compiler complain when I try to use a sun7i define in a
> generic sun4i function (or struct, in this case) - because that would probably
> be causing problems at runtime, too. Better to catch problems earlier.
> So I kept the sun7i-specific things closely together and as much to the bottom
> of the file as possible - as a poor-mans modularity.
> If I kept the sun7i defines at the top I could use them anywhere with impunity -
> also in the A10 case - and it would not complain.
>
> But it's mostly to make the life of the developer easier, so feel free to choose
> otherwise. (not sarcasm)
I understand your point to develop it, but now, the development is done :)
Having all the defines packed together is easier to read and maintain
after the development is done.
> > > 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 :)
>
> The only somewhat important part of the name is the "7".
> If you use a "7"-register on an A10, it's not going to work at runtime, or worse:
> do something else that wasn't intended. Right now it has a "4" although it isn't
> an A10 register. This separation should be visible somewhere in the source code,
> or problems are going to slip through later.
>
> I agree it's not at all important right now because the register is unused
> by us :P
Exactly my point ;)
Like I said, if you want to rename it, go ahead. It would also be a
good idea to open a github issue on allwinner's documentation repo to
make them know that the register name doesn't match between the
register list and the register documentations.
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 --]
next prev parent reply other threads:[~2015-12-18 10:19 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
2015-12-16 10:47 ` Maxime Ripard
2015-12-16 10:47 ` Maxime Ripard
2015-12-16 22:30 ` Danny Milosavljevic
2015-12-16 22:30 ` [linux-sunxi] " Danny Milosavljevic
2015-12-16 22:30 ` Danny Milosavljevic
2015-12-18 10:19 ` Maxime Ripard [this message]
2015-12-18 10:19 ` Maxime Ripard
2015-12-18 10:19 ` Maxime Ripard
2015-12-21 18:41 ` Danny Milosavljevic
2015-12-21 18:41 ` [linux-sunxi] " 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=20151218101943.GI30359@lukather \
--to=maxime.ripard-wi1+55scjutkeb57/3fjtnbpr1lh4cv8@public.gmane.org \
--cc=alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=dannym-bxPqe3T81XXwRsdMLXbzog@public.gmane.org \
--cc=lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
--cc=perex-/Fr2/VpizcU@public.gmane.org \
--cc=tiwai-IBi9RG/b67k@public.gmane.org \
--cc=wens-jdAy2FN1RRM@public.gmane.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.