From: Bo Shen <voice.shen@atmel.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: plagnioj@jcrosoft.com, nicolas.ferre@atmel.com,
linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org, linux-sound@vger.kernel.org,
alsa-devel@alsa-project.org
Subject: Re: [PATCH v5 2/3] ASoC: atmel-ssc-dai: register dai and pcm directly
Date: Tue, 13 Nov 2012 17:10:26 +0800 [thread overview]
Message-ID: <50A20E82.9020704@atmel.com> (raw)
In-Reply-To: <20121113083031.GP18224@opensource.wolfsonmicro.com>
Hi Mark,
On 11/13/2012 16:30, Mark Brown wrote:
> On Mon, Nov 12, 2012 at 03:40:26PM +0800, Bo Shen wrote:
>
>> static struct platform_device sam9g20ek_audio_device = {
>> .name = "at91sam9g20ek-audio",
>> - .id = -1,
>> + .id = 0,
>> };
>
> Why are you changing this? Single devices are supposed to specify -1 as
> their id.
This is for non-dt support, using the id to tell which ssc will be used
to remap into audio subsystem. Maybe this is a mixed up usage, however I
can not find good solution, any suggestions?
This is a similar implement as 7840487cd6298f9f931103b558290d8d98d41c49
>> static int atmel_ssc_startup(struct snd_pcm_substream *substream,
>> struct snd_soc_dai *dai)
>> {
>> - struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
>> + struct atmel_ssc_info *ssc_p = &ssc_info;
>
> This seems like a very big step backwards, there's now a single global
> variable for the ssc_info which presumably means there can be only one
> SSC active in the system at once. That's changing a lot more than just
> the registration...
This change won't broke other subsystem using ssc, only broke the audio
subsystem if there are two codecs co-exist in a system.
I will fix this in next version.
Yes, this patch is a little more than registration, however when change
the registration method, the related code will be affected, so also
clean up them in this patch, do I need to split this patch?
Thanks.
Best Regards,
Bo Shen
WARNING: multiple messages have this Message-ID (diff)
From: Bo Shen <voice.shen@atmel.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: plagnioj@jcrosoft.com, nicolas.ferre@atmel.com,
linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org, linux-sound@vger.kernel.org,
alsa-devel@alsa-project.org
Subject: Re: [PATCH v5 2/3] ASoC: atmel-ssc-dai: register dai and pcm directly
Date: Tue, 13 Nov 2012 09:10:26 +0000 [thread overview]
Message-ID: <50A20E82.9020704@atmel.com> (raw)
In-Reply-To: <20121113083031.GP18224@opensource.wolfsonmicro.com>
Hi Mark,
On 11/13/2012 16:30, Mark Brown wrote:
> On Mon, Nov 12, 2012 at 03:40:26PM +0800, Bo Shen wrote:
>
>> static struct platform_device sam9g20ek_audio_device = {
>> .name = "at91sam9g20ek-audio",
>> - .id = -1,
>> + .id = 0,
>> };
>
> Why are you changing this? Single devices are supposed to specify -1 as
> their id.
This is for non-dt support, using the id to tell which ssc will be used
to remap into audio subsystem. Maybe this is a mixed up usage, however I
can not find good solution, any suggestions?
This is a similar implement as 7840487cd6298f9f931103b558290d8d98d41c49
>> static int atmel_ssc_startup(struct snd_pcm_substream *substream,
>> struct snd_soc_dai *dai)
>> {
>> - struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
>> + struct atmel_ssc_info *ssc_p = &ssc_info;
>
> This seems like a very big step backwards, there's now a single global
> variable for the ssc_info which presumably means there can be only one
> SSC active in the system at once. That's changing a lot more than just
> the registration...
This change won't broke other subsystem using ssc, only broke the audio
subsystem if there are two codecs co-exist in a system.
I will fix this in next version.
Yes, this patch is a little more than registration, however when change
the registration method, the related code will be affected, so also
clean up them in this patch, do I need to split this patch?
Thanks.
Best Regards,
Bo Shen
WARNING: multiple messages have this Message-ID (diff)
From: voice.shen@atmel.com (Bo Shen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 2/3] ASoC: atmel-ssc-dai: register dai and pcm directly
Date: Tue, 13 Nov 2012 17:10:26 +0800 [thread overview]
Message-ID: <50A20E82.9020704@atmel.com> (raw)
In-Reply-To: <20121113083031.GP18224@opensource.wolfsonmicro.com>
Hi Mark,
On 11/13/2012 16:30, Mark Brown wrote:
> On Mon, Nov 12, 2012 at 03:40:26PM +0800, Bo Shen wrote:
>
>> static struct platform_device sam9g20ek_audio_device = {
>> .name = "at91sam9g20ek-audio",
>> - .id = -1,
>> + .id = 0,
>> };
>
> Why are you changing this? Single devices are supposed to specify -1 as
> their id.
This is for non-dt support, using the id to tell which ssc will be used
to remap into audio subsystem. Maybe this is a mixed up usage, however I
can not find good solution, any suggestions?
This is a similar implement as 7840487cd6298f9f931103b558290d8d98d41c49
>> static int atmel_ssc_startup(struct snd_pcm_substream *substream,
>> struct snd_soc_dai *dai)
>> {
>> - struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
>> + struct atmel_ssc_info *ssc_p = &ssc_info;
>
> This seems like a very big step backwards, there's now a single global
> variable for the ssc_info which presumably means there can be only one
> SSC active in the system at once. That's changing a lot more than just
> the registration...
This change won't broke other subsystem using ssc, only broke the audio
subsystem if there are two codecs co-exist in a system.
I will fix this in next version.
Yes, this patch is a little more than registration, however when change
the registration method, the related code will be affected, so also
clean up them in this patch, do I need to split this patch?
Thanks.
Best Regards,
Bo Shen
next prev parent reply other threads:[~2012-11-13 9:10 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-12 7:40 [PATCH v5 0/3] Add pinctrl support and enable audio Bo Shen
2012-11-12 7:40 ` Bo Shen
2012-11-12 7:40 ` Bo Shen
2012-11-12 7:40 ` [PATCH v5 1/3] ARM: at91: atmel-ssc: add pinctrl support Bo Shen
2012-11-12 7:40 ` Bo Shen
2012-11-12 7:40 ` Bo Shen
2012-11-13 8:50 ` Mark Brown
2012-11-13 8:50 ` Mark Brown
2012-11-13 8:50 ` Mark Brown
[not found] ` <20121113085052.GR18224-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-11-14 6:30 ` Bo Shen
2012-11-14 6:30 ` Bo Shen
2012-11-14 6:30 ` Bo Shen
2012-11-12 7:40 ` [PATCH v5 2/3] ASoC: atmel-ssc-dai: register dai and pcm directly Bo Shen
2012-11-12 7:40 ` Bo Shen
2012-11-12 7:40 ` Bo Shen
2012-11-13 8:30 ` Mark Brown
2012-11-13 8:30 ` Mark Brown
2012-11-13 8:30 ` Mark Brown
2012-11-13 9:10 ` Bo Shen [this message]
2012-11-13 9:10 ` Bo Shen
2012-11-13 9:10 ` Bo Shen
2012-11-13 9:20 ` Mark Brown
2012-11-13 9:20 ` Mark Brown
2012-11-13 9:20 ` Mark Brown
2012-11-13 9:38 ` Bo Shen
2012-11-13 9:38 ` Bo Shen
2012-11-13 9:38 ` Bo Shen
2012-11-13 9:41 ` Mark Brown
2012-11-13 9:41 ` Mark Brown
2012-11-13 9:41 ` Mark Brown
2012-11-13 9:52 ` Bo Shen
2012-11-13 9:52 ` Bo Shen
2012-11-13 9:52 ` Bo Shen
2012-11-12 7:40 ` [PATCH 3/3] ASoC: at91sam9g20ek-wm8731: convert to dt support Bo Shen
2012-11-12 7:40 ` Bo Shen
2012-11-12 7:40 ` Bo Shen
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=50A20E82.9020704@atmel.com \
--to=voice.shen@atmel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-sound@vger.kernel.org \
--cc=nicolas.ferre@atmel.com \
--cc=plagnioj@jcrosoft.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.