From: Bo Shen <voice.shen@atmel.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, devicetree-discuss@lists.ozlabs.org,
nicolas.ferre@atmel.com, linux-sound@vger.kernel.org,
plagnioj@jcrosoft.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC patch v3 3/4] ASoC: atmel-ssc-dai: register dai and pcm directly
Date: Wed, 07 Nov 2012 15:38:24 +0800 [thread overview]
Message-ID: <509A0FF0.7030501@atmel.com> (raw)
In-Reply-To: <20121106113908.GC10080@opensource.wolfsonmicro.com>
On 11/6/2012 19:39, Mark Brown wrote:
> On Tue, Nov 06, 2012 at 05:32:32PM +0800, Bo Shen wrote:
>> On 11/6/2012 16:48, Mark Brown wrote:
>>> On Tue, Nov 06, 2012 at 01:57:53PM +0800, Bo Shen wrote:
>
>>> No, this isn't converting things to device tree which presumably is the
>>> goal here and obviously just doing the rename doesn't accomplish an
>>> enormous amount. What I said was that you should instantiate the ASoC
>>> adaption when the machine driver needs to use them. You shouldn't even
>>> need a separate device for this.
>
>> Maybe this is not the best solution, but just abstract audio as a
>> separate device. The other's still keep as a ssc library.
>
> It's not abstracting things, that's the whole problem. It's putting the
> internals of how the Linux audio stack is organised into the device
> tree. The point is that the SSC should be a library to all users.
OK. I will keep the SSC as a library for all users.
>>> Please do look at other platforms with similar hardware and do something
>>> similar to them.
>
>> I take some reference (e.g: freescale, marvell, invidia soc, this
>> RFC implement is similar with them), but don't find the similar
>> hardware with us. Please help provide the information who's HW is
>> similar with us. Thanks.
>
> A *huge* range of SoCs have generic serial ports - off the top of my
> head this includes at least OMAP, PXA and Freescale. The same issue
> also applies to DMA controllers which affects almost all SoCs.
Thanks for this information, I will try to implement the SSC framework
like this. If it is finished, I will send out v4 patch series.
Thanks again.
BRs,
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: alsa-devel@alsa-project.org, devicetree-discuss@lists.ozlabs.org,
nicolas.ferre@atmel.com, linux-sound@vger.kernel.org,
plagnioj@jcrosoft.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC patch v3 3/4] ASoC: atmel-ssc-dai: register dai and pcm directly
Date: Wed, 07 Nov 2012 07:38:24 +0000 [thread overview]
Message-ID: <509A0FF0.7030501@atmel.com> (raw)
In-Reply-To: <20121106113908.GC10080@opensource.wolfsonmicro.com>
On 11/6/2012 19:39, Mark Brown wrote:
> On Tue, Nov 06, 2012 at 05:32:32PM +0800, Bo Shen wrote:
>> On 11/6/2012 16:48, Mark Brown wrote:
>>> On Tue, Nov 06, 2012 at 01:57:53PM +0800, Bo Shen wrote:
>
>>> No, this isn't converting things to device tree which presumably is the
>>> goal here and obviously just doing the rename doesn't accomplish an
>>> enormous amount. What I said was that you should instantiate the ASoC
>>> adaption when the machine driver needs to use them. You shouldn't even
>>> need a separate device for this.
>
>> Maybe this is not the best solution, but just abstract audio as a
>> separate device. The other's still keep as a ssc library.
>
> It's not abstracting things, that's the whole problem. It's putting the
> internals of how the Linux audio stack is organised into the device
> tree. The point is that the SSC should be a library to all users.
OK. I will keep the SSC as a library for all users.
>>> Please do look at other platforms with similar hardware and do something
>>> similar to them.
>
>> I take some reference (e.g: freescale, marvell, invidia soc, this
>> RFC implement is similar with them), but don't find the similar
>> hardware with us. Please help provide the information who's HW is
>> similar with us. Thanks.
>
> A *huge* range of SoCs have generic serial ports - off the top of my
> head this includes at least OMAP, PXA and Freescale. The same issue
> also applies to DMA controllers which affects almost all SoCs.
Thanks for this information, I will try to implement the SSC framework
like this. If it is finished, I will send out v4 patch series.
Thanks again.
BRs,
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: [RFC patch v3 3/4] ASoC: atmel-ssc-dai: register dai and pcm directly
Date: Wed, 07 Nov 2012 15:38:24 +0800 [thread overview]
Message-ID: <509A0FF0.7030501@atmel.com> (raw)
In-Reply-To: <20121106113908.GC10080@opensource.wolfsonmicro.com>
On 11/6/2012 19:39, Mark Brown wrote:
> On Tue, Nov 06, 2012 at 05:32:32PM +0800, Bo Shen wrote:
>> On 11/6/2012 16:48, Mark Brown wrote:
>>> On Tue, Nov 06, 2012 at 01:57:53PM +0800, Bo Shen wrote:
>
>>> No, this isn't converting things to device tree which presumably is the
>>> goal here and obviously just doing the rename doesn't accomplish an
>>> enormous amount. What I said was that you should instantiate the ASoC
>>> adaption when the machine driver needs to use them. You shouldn't even
>>> need a separate device for this.
>
>> Maybe this is not the best solution, but just abstract audio as a
>> separate device. The other's still keep as a ssc library.
>
> It's not abstracting things, that's the whole problem. It's putting the
> internals of how the Linux audio stack is organised into the device
> tree. The point is that the SSC should be a library to all users.
OK. I will keep the SSC as a library for all users.
>>> Please do look at other platforms with similar hardware and do something
>>> similar to them.
>
>> I take some reference (e.g: freescale, marvell, invidia soc, this
>> RFC implement is similar with them), but don't find the similar
>> hardware with us. Please help provide the information who's HW is
>> similar with us. Thanks.
>
> A *huge* range of SoCs have generic serial ports - off the top of my
> head this includes at least OMAP, PXA and Freescale. The same issue
> also applies to DMA controllers which affects almost all SoCs.
Thanks for this information, I will try to implement the SSC framework
like this. If it is finished, I will send out v4 patch series.
Thanks again.
BRs,
Bo Shen
next prev parent reply other threads:[~2012-11-07 7:39 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 5:57 [RFC patch v3 1/4] ARM: at91: atmel-ssc: add platform device id table Bo Shen
2012-11-06 5:57 ` Bo Shen
2012-11-06 5:57 ` Bo Shen
2012-11-06 5:57 ` [RFC patch v3 2/4] ARM: at91: atmel-ssc: add device tree support Bo Shen
2012-11-06 5:57 ` Bo Shen
2012-11-06 5:57 ` Bo Shen
2012-11-06 8:58 ` Mark Brown
2012-11-06 8:58 ` Mark Brown
2012-11-06 8:58 ` Mark Brown
2012-11-06 5:57 ` [RFC patch v3 3/4] ASoC: atmel-ssc-dai: register dai and pcm directly Bo Shen
2012-11-06 5:57 ` Bo Shen
2012-11-06 5:57 ` Bo Shen
2012-11-06 8:48 ` Mark Brown
2012-11-06 8:48 ` Mark Brown
2012-11-06 8:48 ` Mark Brown
2012-11-06 9:32 ` Bo Shen
2012-11-06 9:32 ` Bo Shen
2012-11-06 9:32 ` Bo Shen
2012-11-06 11:39 ` Mark Brown
2012-11-06 11:39 ` Mark Brown
2012-11-06 11:39 ` Mark Brown
2012-11-07 7:38 ` Bo Shen [this message]
2012-11-07 7:38 ` Bo Shen
2012-11-07 7:38 ` Bo Shen
2012-11-06 5:57 ` [RFC patch v3 4/4] ASoC: sam9g20-wm8731: convert dt support Bo Shen
2012-11-06 5:57 ` Bo Shen
2012-11-06 5:57 ` Bo Shen
2012-11-06 8:58 ` [RFC patch v3 1/4] ARM: at91: atmel-ssc: add platform device id table Mark Brown
2012-11-06 8:58 ` Mark Brown
2012-11-06 8:58 ` Mark Brown
[not found] ` <1352181474-19597-1-git-send-email-voice.shen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-11-06 14:52 ` Jean-Christophe PLAGNIOL-VILLARD
2012-11-06 14:52 ` Jean-Christophe PLAGNIOL-VILLARD
2012-11-06 14:52 ` Jean-Christophe PLAGNIOL-VILLARD
2012-11-06 15:29 ` Nicolas Ferre
2012-11-06 15:29 ` Nicolas Ferre
2012-11-06 15:29 ` Nicolas Ferre
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=509A0FF0.7030501@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.