Hi Lars
Thank you for your idea
> To be honest I'd also get rid of DAIs has a top level concept. This image
> (http://metafoo.de/the_new_asoc.svg) is something I've put together awhile
> ago how I think we should lay things out if we do a major refactoring of the
> ASoC core.
I think most impor
On Thu, Aug 04, 2016 at 10:21:10AM +0200, Lars-Peter Clausen wrote:
> To be honest I'd also get rid of DAIs has a top level concept. This image
> (http://metafoo.de/the_new_asoc.svg) is something I've put together awhile
> ago how I think we should lay things out if we do a major refactoring of th
On Thu, Aug 04, 2016 at 02:38:33AM +, Kuninori Morimoto wrote:
> I agree to your opinion.
> OTOH, we would like to use/keep existing current all drivers.
> Thus, I think we need super many small and slow steps.
> Or, we need new ASoC2 ?
Small steps is how we do things in the kernel.
> OTOH
On 08/04/2016 04:38 AM, Kuninori Morimoto wrote:
>
> Hi Lars
>
>> I think moving forward we should get rid of the whole CPU/CODEC/platform
>> concept. This is an outdated view of how the hardware looks like. When ASoC
>> was initially introduce all hardware basically had a CPU side DAI, a CODEC
>
Hi Lars
> I think moving forward we should get rid of the whole CPU/CODEC/platform
> concept. This is an outdated view of how the hardware looks like. When ASoC
> was initially introduce all hardware basically had a CPU side DAI, a CODEC
> side DAI and a DMA. The DMA was connected to the CPU DAI
On 08/02/2016 08:47 AM, Kuninori Morimoto wrote:
>
> Hi Lars, Mark
>
> My previous mail was missing point...
>
In my opinion the flags are just as much a hack as the pointer. In an ideal
setup the component does not need to know what type it is. The reason why
we
need this i
Hi Lars, Mark
My previous mail was missing point...
> > > In my opinion the flags are just as much a hack as the pointer. In an
> > > ideal
> > > setup the component does not need to know what type it is. The reason why
> > > we
> > > need this in ASoC is because the framework has grown over t
Hi Lars, Mark
> > In my opinion the flags are just as much a hack as the pointer. In an ideal
> > setup the component does not need to know what type it is. The reason why we
> > need this in ASoC is because the framework has grown over time and we need
> > to support legacy code.
>
> Yes, the p
On Fri, Jul 29, 2016 at 11:01:27AM +0200, Lars-Peter Clausen wrote:
> In my opinion the flags are just as much a hack as the pointer. In an ideal
> setup the component does not need to know what type it is. The reason why we
> need this in ASoC is because the framework has grown over time and we n
On 07/29/2016 04:24 AM, Kuninori Morimoto wrote:
>
> Hi Lars
>
> Thank you for your feedback
>
>>> int snd_soc_runtime_set_dai_fmt(xxx)
>>> {
>>> ...
>>> /* Flip the polarity for the "CPU" end of a CODEC<->CODEC link */
>>> if (cpu_dai->codec) {
>>> ...
>>> }
>>>
Hi Lars
Thank you for your feedback
> > int snd_soc_runtime_set_dai_fmt(xxx)
> > {
> > ...
> > /* Flip the polarity for the "CPU" end of a CODEC<->CODEC link */
> > if (cpu_dai->codec) {
> > ...
> > }
> > ...
> > }
(snip)
> This is for CODEC<->CODEC links where no
On 07/28/2016 10:42 PM, Takashi Iwai wrote:
> On Thu, 28 Jul 2016 22:33:31 +0200,
> Lars-Peter Clausen wrote:
>>
>> On 07/28/2016 05:46 AM, Vinod Koul wrote:
>>> On Wed, Jul 27, 2016 at 10:22:41PM +0200, Takashi Iwai wrote:
On Wed, 27 Jul 2016 20:22:33 +0200,
Mark Brown wrote:
>
>
On Thu, Jul 28, 2016 at 10:33:31PM +0200, Lars-Peter Clausen wrote:
> On 07/28/2016 05:46 AM, Vinod Koul wrote:
> > I agree, it makese no sense for devices to be hotplugged. And for
> > developement flows people can do rmmond and insmod. That works fine!
> I don't agree. In my opinion hot-plug is
On Thu, 28 Jul 2016 22:33:31 +0200,
Lars-Peter Clausen wrote:
>
> On 07/28/2016 05:46 AM, Vinod Koul wrote:
> > On Wed, Jul 27, 2016 at 10:22:41PM +0200, Takashi Iwai wrote:
> >> On Wed, 27 Jul 2016 20:22:33 +0200,
> >> Mark Brown wrote:
> >>>
> >>> On Wed, Jul 27, 2016 at 08:11:49PM +0200, Takash
On 07/28/2016 05:46 AM, Vinod Koul wrote:
> On Wed, Jul 27, 2016 at 10:22:41PM +0200, Takashi Iwai wrote:
>> On Wed, 27 Jul 2016 20:22:33 +0200,
>> Mark Brown wrote:
>>>
>>> On Wed, Jul 27, 2016 at 08:11:49PM +0200, Takashi Iwai wrote:
>>>
I'm wondering whether it's a better option to block th
On 07/26/2016 07:41 AM, Kuninori Morimoto wrote:
>
> Hi ALSA SoC
>
> My current headache is ALSA SoC's each modules (= Card/Codec/CPU/Platform)
> doesn't care about "unbind/rmmod".
> For example, if someone unbinded/rmmoded "Codec", Card or other modules
> doesn't know about it. Thus, user can co
On Wed, Jul 27, 2016 at 10:22:41PM +0200, Takashi Iwai wrote:
> On Wed, 27 Jul 2016 20:22:33 +0200,
> Mark Brown wrote:
> >
> > On Wed, Jul 27, 2016 at 08:11:49PM +0200, Takashi Iwai wrote:
> >
> > > I'm wondering whether it's a better option to block the unbind
> > > behavior, either in driver b
On Wed, 27 Jul 2016 20:22:33 +0200,
Mark Brown wrote:
>
> On Wed, Jul 27, 2016 at 08:11:49PM +0200, Takashi Iwai wrote:
>
> > I'm wondering whether it's a better option to block the unbind
> > behavior, either in driver base (allowing to return an error) or in
> > the sound side (waiting in remov
On Wed, 27 Jul 2016 20:04:56 +0200,
Mark Brown wrote:
>
> On Wed, Jul 27, 2016 at 10:51:26PM +0530, Vinod Koul wrote:
> > On Wed, Jul 27, 2016 at 07:57:05AM +0200, Takashi Iwai wrote:
>
> > > For unloading the module, yes, it should have been prevented by
> > > managing the module refcount. Howe
On Wed, Jul 27, 2016 at 08:11:49PM +0200, Takashi Iwai wrote:
> I'm wondering whether it's a better option to block the unbind
> behavior, either in driver base (allowing to return an error) or in
> the sound side (waiting in remove() until the sane point).
That's certainly going to be a lot eas
On Wed, Jul 27, 2016 at 10:51:26PM +0530, Vinod Koul wrote:
> On Wed, Jul 27, 2016 at 07:57:05AM +0200, Takashi Iwai wrote:
> > For unloading the module, yes, it should have been prevented by
> > managing the module refcount. However, unbinding can't be stopped by
> > that. It's a known problem.
On Wed, Jul 27, 2016 at 07:57:05AM +0200, Takashi Iwai wrote:
> On Wed, 27 Jul 2016 05:21:11 +0200,
> Vinod Koul wrote:
> >
> > On Tue, Jul 26, 2016 at 05:41:56AM +, Kuninori Morimoto wrote:
> > >
> > > Hi ALSA SoC
> > >
> > > My current headache is ALSA SoC's each modules (= Card/Codec/CPU/
Hi Takashi-san
Thank you for your help
> > > My current headache is ALSA SoC's each modules (= Card/Codec/CPU/Platform)
> > > doesn't care about "unbind/rmmod".
> > > For example, if someone unbinded/rmmoded "Codec", Card or other modules
> > > doesn't know about it. Thus, user can continue to u
On Wed, 27 Jul 2016 05:21:11 +0200,
Vinod Koul wrote:
>
> On Tue, Jul 26, 2016 at 05:41:56AM +, Kuninori Morimoto wrote:
> >
> > Hi ALSA SoC
> >
> > My current headache is ALSA SoC's each modules (= Card/Codec/CPU/Platform)
> > doesn't care about "unbind/rmmod".
> > For example, if someone u
Hi Vinod
> > My current headache is ALSA SoC's each modules (= Card/Codec/CPU/Platform)
> > doesn't care about "unbind/rmmod".
> > For example, if someone unbinded/rmmoded "Codec", Card or other modules
> > doesn't know about it. Thus, user can continue to use this sound card,
> > and kernel will
On Tue, Jul 26, 2016 at 05:41:56AM +, Kuninori Morimoto wrote:
>
> Hi ALSA SoC
>
> My current headache is ALSA SoC's each modules (= Card/Codec/CPU/Platform)
> doesn't care about "unbind/rmmod".
> For example, if someone unbinded/rmmoded "Codec", Card or other modules
> doesn't know about it.
26 matches
Mail list logo
