All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.