All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@nokia.com>
To: ext Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "tony@atomide.com" <tony@atomide.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"sameo@linux.intel.com" <sameo@linux.intel.com>
Subject: Re: [PATCH 4/4] ASoC: TWL4030: Driver registration via twl4030_codec MFD
Date: Tue, 20 Oct 2009 14:30:49 +0300	[thread overview]
Message-ID: <200910201430.49223.peter.ujfalusi@nokia.com> (raw)
In-Reply-To: <20091020102540.GB28592@opensource.wolfsonmicro.com>

On Tuesday 20 October 2009 13:25:40 ext Mark Brown wrote:
> On Mon, Oct 19, 2009 at 03:42:20PM +0300, Peter Ujfalusi wrote:
> > TWL4030 codec is now using the device registration via
> > tlw4030_codec MFD device.
> 
> This looks pretty good but obviously depends on the MFD changes.

Thanks, yes it all depends on the MFD changes.

> The major thing that jumps out at me is the removal of the register
> definitions from the ASoC headers - it might be nice to have that done
> as part of the MFD patch, or as a separate patch.

The reason why I have done it like this is that with one patch I only touch one 
subsystem at the time:
1. MFD changes only
2. OMAP related changes
3. soc codec driver change

In patch 1, the register definitions had to be added, so that the twl4030_codec 
driver knows the registers (and there could be the vibra driver placed 
separately from the soc codec driver).
In patch 3, where I modify the soc codec driver to use the new method, than I 
remove the definitions and use the existing header file, introduced by the first 
patch.
All in all, after each patch the kernel can be builds, boots and works as 
before.

> 
> You've also got the bias being brought up when the ASoC system comes up
> rather than when the driver comes up.  To be honest it doesn't really
> make any difference either way, it's just slightly different to other
> drivers.

I was thinking that if you built the kernel with SND_SOC_ALL_CODECS on OMAP 
platform for some reason and you don't actually use the twl4030 as audio device 
-> no machine driver, which would use it, than the codec part would be off.
But yes, probably I can move the povering up to the probe function.

> What is useful with things like twl4030 which take a little
> while to come up is if you can do the bias bringup out of line from
> device probe, avoiding blocking system startup on CODEC bringup.  That's
> definitely a separate patch, I'm just mentioning it for interest here.

I'm sure there will be another round for this series, so I can make this change 
at the same time within the patch, since this anyway changes the way how the 
driver is loaded/probed.

> 
> There's also a couple of debug prints (like in the remove function) and

I'll get rid of them.
But at least this time I did not had those unneeded casts, which I usually have 
;)

> 
> > +MODULE_ALIAS("platform:twl4030_codec:audio");
> 
> Is that second colon right given...

I'm not sure about it at all either. I did not found any other 'nested MFD' 
drivers around, so this is just a guess
Should it be:

 +MODULE_ALIAS("platform:twl4030_codec_audio");


> 
> > +	.driver		= {
> > +		.name	= "twl4030_codec_audio",
> > +		.owner	= THIS_MODULE,
> 
> this.
> 

-- 
Péter

WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@nokia.com>
To: ext Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"sameo@linux.intel.com" <sameo@linux.intel.com>,
	"tony@atomide.com" <tony@atomide.com>
Subject: Re: [PATCH 4/4] ASoC: TWL4030: Driver registration via twl4030_codec MFD
Date: Tue, 20 Oct 2009 14:30:49 +0300	[thread overview]
Message-ID: <200910201430.49223.peter.ujfalusi@nokia.com> (raw)
In-Reply-To: <20091020102540.GB28592@opensource.wolfsonmicro.com>

On Tuesday 20 October 2009 13:25:40 ext Mark Brown wrote:
> On Mon, Oct 19, 2009 at 03:42:20PM +0300, Peter Ujfalusi wrote:
> > TWL4030 codec is now using the device registration via
> > tlw4030_codec MFD device.
> 
> This looks pretty good but obviously depends on the MFD changes.

Thanks, yes it all depends on the MFD changes.

> The major thing that jumps out at me is the removal of the register
> definitions from the ASoC headers - it might be nice to have that done
> as part of the MFD patch, or as a separate patch.

The reason why I have done it like this is that with one patch I only touch one 
subsystem at the time:
1. MFD changes only
2. OMAP related changes
3. soc codec driver change

In patch 1, the register definitions had to be added, so that the twl4030_codec 
driver knows the registers (and there could be the vibra driver placed 
separately from the soc codec driver).
In patch 3, where I modify the soc codec driver to use the new method, than I 
remove the definitions and use the existing header file, introduced by the first 
patch.
All in all, after each patch the kernel can be builds, boots and works as 
before.

> 
> You've also got the bias being brought up when the ASoC system comes up
> rather than when the driver comes up.  To be honest it doesn't really
> make any difference either way, it's just slightly different to other
> drivers.

I was thinking that if you built the kernel with SND_SOC_ALL_CODECS on OMAP 
platform for some reason and you don't actually use the twl4030 as audio device 
-> no machine driver, which would use it, than the codec part would be off.
But yes, probably I can move the povering up to the probe function.

> What is useful with things like twl4030 which take a little
> while to come up is if you can do the bias bringup out of line from
> device probe, avoiding blocking system startup on CODEC bringup.  That's
> definitely a separate patch, I'm just mentioning it for interest here.

I'm sure there will be another round for this series, so I can make this change 
at the same time within the patch, since this anyway changes the way how the 
driver is loaded/probed.

> 
> There's also a couple of debug prints (like in the remove function) and

I'll get rid of them.
But at least this time I did not had those unneeded casts, which I usually have 
;)

> 
> > +MODULE_ALIAS("platform:twl4030_codec:audio");
> 
> Is that second colon right given...

I'm not sure about it at all either. I did not found any other 'nested MFD' 
drivers around, so this is just a guess
Should it be:

 +MODULE_ALIAS("platform:twl4030_codec_audio");


> 
> > +	.driver		= {
> > +		.name	= "twl4030_codec_audio",
> > +		.owner	= THIS_MODULE,
> 
> this.
> 

-- 
Péter

  reply	other threads:[~2009-10-20 11:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-19 12:42 [PATCH 0/4] twl4030 codec as MFD device Peter Ujfalusi
2009-10-19 12:42 ` [PATCH 1/4] MFD: twl4030: add twl4030_codec MFD as a new child to the core Peter Ujfalusi
2009-10-19 12:42   ` Peter Ujfalusi
2009-10-19 12:42   ` [PATCH 2/4] OMAP: Platform support for twl4030_codec MFD Peter Ujfalusi
2009-10-19 12:42     ` Peter Ujfalusi
2009-10-19 12:42     ` [PATCH 3/4] ASoC: TWL4030: Only update the needed bits in *set_dai_sysclk Peter Ujfalusi
2009-10-19 12:42       ` Peter Ujfalusi
2009-10-19 12:42       ` [PATCH 4/4] ASoC: TWL4030: Driver registration via twl4030_codec MFD Peter Ujfalusi
2009-10-19 12:42         ` Peter Ujfalusi
2009-10-20 10:25         ` Mark Brown
2009-10-20 11:30           ` Peter Ujfalusi [this message]
2009-10-20 11:30             ` Peter Ujfalusi
2009-10-20 11:51             ` Mark Brown
2009-10-20 11:51               ` Mark Brown
2009-10-20 12:01               ` Peter Ujfalusi
2009-10-20 12:01                 ` Peter Ujfalusi
2009-10-19 12:55       ` [PATCH 3/4] ASoC: TWL4030: Only update the needed bits in *set_dai_sysclk Mark Brown
2009-10-19 12:59         ` Peter Ujfalusi
2009-10-19 12:59           ` Peter Ujfalusi
2009-10-20 19:01     ` [PATCH 2/4] OMAP: Platform support for twl4030_codec MFD Tony Lindgren
2009-10-20 19:01       ` Tony Lindgren
2009-10-20 10:03   ` [PATCH 1/4] MFD: twl4030: add twl4030_codec MFD as a new child to the core Mark Brown
2009-10-20 10:03     ` Mark Brown
2009-10-20 11:16     ` Peter Ujfalusi
2009-10-20 11:16       ` [alsa-devel] " Peter Ujfalusi
2009-10-21 23:13   ` Samuel Ortiz
2009-10-22  6:04     ` Peter Ujfalusi
2009-10-22  6:04       ` Peter Ujfalusi
2009-10-22  7:57       ` Samuel Ortiz
2009-10-22 10:55         ` Mark Brown
2009-10-22 10:55           ` Mark Brown
2009-10-22 11:02           ` Peter Ujfalusi
2009-10-22 11:02             ` Peter Ujfalusi
2009-10-21  8:56 ` [PATCH 0/4] twl4030 codec as MFD device Peter Ujfalusi
2009-10-21  8:56   ` Peter Ujfalusi

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=200910201430.49223.peter.ujfalusi@nokia.com \
    --to=peter.ujfalusi@nokia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=tony@atomide.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.