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
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
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.
>
On Thu, 04 Aug 2016 15:39:40 +0200,
Takashi Sakamoto wrote:
>
> On Aug 4 2016 21:27, Takashi Iwai wrote:
> > On Thu, 04 Aug 2016 14:12:09 +0200,
> > Takashi Sakamoto wrote:
> >>
> >> On Aug 4 2016 19:28, Mark Brown wrote:
> >>> On Thu, Aug 04, 2016 at 12:17:57PM +0900, Takashi Sakamoto wrote:
>
On Aug 4 2016 21:27, Takashi Iwai wrote:
> On Thu, 04 Aug 2016 14:12:09 +0200,
> Takashi Sakamoto wrote:
>>
>> On Aug 4 2016 19:28, Mark Brown wrote:
>>> On Thu, Aug 04, 2016 at 12:17:57PM +0900, Takashi Sakamoto wrote:
On Jul 30 2016 07:08, Mark Brown wrote:
>>>
> The card should be
On Thu, 04 Aug 2016 14:12:09 +0200,
Takashi Sakamoto wrote:
>
> On Aug 4 2016 19:28, Mark Brown wrote:
> > On Thu, Aug 04, 2016 at 12:17:57PM +0900, Takashi Sakamoto wrote:
> >> On Jul 30 2016 07:08, Mark Brown wrote:
> >
> >>> The card should be deinstantiated and reinstantiated whenever a
>
On Aug 4 2016 19:28, Mark Brown wrote:
> On Thu, Aug 04, 2016 at 12:17:57PM +0900, Takashi Sakamoto wrote:
>> On Jul 30 2016 07:08, Mark Brown wrote:
>
>>> The card should be deinstantiated and reinstantiated whenever a
>>> component driver unbinds and rebinds (respectively). You'd need to
>>>
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
On Jul 30 2016 07:08, Mark Brown wrote:
But I think it's logically difficult to manage state of sound card; e.g.
disconnect. When one sound card instance consists of instances of
several 'DAI', 'Codecs' and 'Components' (this 'component' is not in
ALSA core contexts[1]) and we try to unload one
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
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
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
On Sat, Jul 30, 2016 at 06:45:04AM +0900, Takashi Sakamoto wrote:
> In a point of 'reuse of codes', I cannot imagine what Lars said for USB
> devices, then post the questions.
Someone might make a fancy device connected via USB which doesn't
conform to the USB specs.
> But I think it's
On Jul 30 2016 05:41, Takashi Iwai wrote:
>> That still seems a bit fancy hardware :)
>>
>> If we can reasonably support this, I am for it. But not making stuff
>> overtly complex...
>
> Yes, we don't have to overreact to a dream immediately now.
As I wrote at first, my question is a sidetrack.
On Fri, 29 Jul 2016 18:07:02 +0200,
Vinod Koul wrote:
>
> On Fri, Jul 29, 2016 at 11:07:49AM +0200, Lars-Peter Clausen wrote:
> > On 07/29/2016 02:30 AM, Takashi Sakamoto wrote:
> > > Lars,
> > >
> > > On Jul 29 2016 05:33, Lars-Peter Clausen wrote:
> > >> Hotplug is something that always pops
On Fri, Jul 29, 2016 at 11:07:49AM +0200, Lars-Peter Clausen wrote:
> On 07/29/2016 02:30 AM, Takashi Sakamoto wrote:
> > Lars,
> >
> > On Jul 29 2016 05:33, Lars-Peter Clausen wrote:
> >> Hotplug is something that always pops up sooner or later. E.g. if someone
> >> puts a ASoC supported CODEC
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) {
>>> ...
>>> }
>>>
On 07/29/2016 02:30 AM, Takashi Sakamoto wrote:
> Lars,
>
> On Jul 29 2016 05:33, Lars-Peter Clausen wrote:
>> Hotplug is something that always pops up sooner or later. E.g. if someone
>> puts a ASoC supported CODEC on a hot-pluggable device (maybe USB) we
>> don't want to duplicate the code, but
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
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
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,
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
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
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
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
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
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
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
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
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
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 continue to use this sound card,
and kernel will be Oops.
So, I
33 matches
Mail list logo
