[PATCHES_v1] ASoC: Towards dropping runtime field from snd_soc_dai

[PATCHES_v1] ASoC: Towards dropping runtime field from snd_soc_dai

[jassi brar]

Hi,

<Due to some problem I am unable to send inline patches, please accept
the attached patches for this time>

The following three patches are aimed at discarding runtime field
from struct snd_soc_dai, which comes in the way of working towards
making it possible to share cpu_dai/codec_dai among two or more dai_links.

[PATCH 1/3] ASoC: PLATFORM: Pass dai_link as argument to suspend, resume
	Also a good idea to provide pointer to relevant dai_link to platform
	suspend/resume. It also makes easy traversing the ASOC links to reach
	the substream(when snd_soc_dai.runtime is dropped).

[PATCH 2/3] ASOC: ATMEL: Getting cpu_dai method change
[PATCH 3/3] ASOC: SND_SOC_DAI: Get rid of 'runtime' field

Regards.

Re: [PATCHES_v1] ASoC: Towards dropping runtime field from snd_soc_dai

[Mark Brown]

On Mon, Feb 22, 2010 at 03:55:59PM +0900, jassi brar wrote:

I've applied all three changes for 2.6.35 after testing on an AT91 board
here, thanks.  Unfortunately it looks like the SSC suspend and resume
code is a bit broken anyway since it doesn't seem to cope too well with
being suspended during playback but your patches don't affect that one
way or another.

> <Due to some problem I am unable to send inline patches, please accept
> the attached patches for this time>

If you're going to do this please send just the patches as the
attachments, including the patch description in the attachment cases
them to come out like this:

    ASOC: ATMEL: Getting cpu_dai method change
    
    [PATCH 2/3] ASOC: ATMEL: Getting cpu_dai method change
    
    Currently only the atmel driver make use of snd_soc_dai.runtime field.

when applied which isn't ideal.  It also seems that your attachments are
coming out base64 encoded rather than text/plain.

> [PATCH 1/3] ASoC: PLATFORM: Pass dai_link as argument to suspend, resume
> [PATCH 2/3] ASOC: ATMEL: Getting cpu_dai method change
> [PATCH 3/3] ASOC: SND_SOC_DAI: Get rid of 'runtime' field

Note also the different spellings of ASoC here (and elsewhere in your
commit messages) - the first is correct.  You don't need to capitalise
all the letters in names.

If your problems are (as I'm guessing is the case) gmail breakage you
might want to look into imap-send, which will dump the patches in an
IMAP mailbox for transmission.

Re: [PATCHES_v1] ASoC: Towards dropping runtime field from snd_soc_dai

[jassi brar]

On Mon, Feb 22, 2010 at 11:27 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Feb 22, 2010 at 03:55:59PM +0900, jassi brar wrote:
>> <Due to some problem I am unable to send inline patches, please accept
>> the attached patches for this time>
>
> If you're going to do this please send just the patches as the
> attachments, including the patch description in the attachment cases
> them to come out like this:
>
>    ASOC: ATMEL: Getting cpu_dai method change
>
>    [PATCH 2/3] ASOC: ATMEL: Getting cpu_dai method change
>
>    Currently only the atmel driver make use of snd_soc_dai.runtime field.
>
> when applied which isn't ideal.
I intended them to be 'git am' applied. Anyways, I hope I don't have to
send attachments in future.

>> [PATCH 1/3] ASoC: PLATFORM: Pass dai_link as argument to suspend, resume
>> [PATCH 2/3] ASOC: ATMEL: Getting cpu_dai method change
>> [PATCH 3/3] ASOC: SND_SOC_DAI: Get rid of 'runtime' field
>
> Note also the different spellings of ASoC here (and elsewhere in your
> commit messages) - the first is correct.  You don't need to capitalise
> all the letters in names.
Ok.

> If your problems are (as I'm guessing is the case) gmail breakage you
> might want to look into imap-send, which will dump the patches in an
> IMAP mailbox for transmission.
will check that out.
thanks.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCHES_v1] ASoC: Towards dropping runtime field from snd_soc_dai

[Mark Brown]

On Tue, Feb 23, 2010 at 01:57:30PM +0900, jassi brar wrote:

> I intended them to be 'git am' applied. Anyways, I hope I don't have to
> send attachments in future.

Yes, that was what I used to apply them - essentially what it does is to
stick the contents of the attachment onto the message subject and body
that it would normally use then process them so anything in the patch
that's replicated from the subject and body will end up at the end of
the body.