Re: [PATCH] ASoC: omap-mcbsp: Fix compilation error due to leftover code

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

Hi Mark,

On 08/30/2012 09:02 PM, Mark Brown wrote:
> On Thu, Aug 30, 2012 at 05:06:15PM +0300, Peter Ujfalusi wrote:
>> Part of commit (which patches sound/soc/omap/mcbsp.c file):
>> 8fef626 ARM/ASoC: omap-mcbsp: Remove CLKR/FSR mux configuration code
>>
>> since the tree where it has been applied did not had the earlier patch:
>> d0db84e ASoC: omap-mcbsp: Fix 6pin mux configuration
>> which changed code around omap_mcbsp_6pin_src_mux().
>>
>> Because of the missing part from 8fef626 the sound/soc/omap/mcbsp.c does
>> not compile in linux-next.
> 
> This makes little sense to me.  If the other patch is a dependency why
> not merge that dependency?  What does this mean at the code level?

Commit d0db84e ASoC: omap-mcbsp: Fix 6pin mux configuration

changed a line within omap_mcbsp_6pin_src_mux() function to fix an error which
prevents the mux configuration in 3.4, 3.5, 3.6 kernels.

Commit 8fef626 ARM/ASoC: omap-mcbsp: Remove CLKR/FSR mux configuration code

should remove this function fir 3.7 and the mux configuration should be done
in the board files or via DTS.

You have reported when you applied the McBSP DT series that commit 8fef626 had
conflict when you applied it. This was because I have created the series on on
a branch where the 6pin function was already fixed since I knew it is going to
be in 3.6 when the 3.7 merge will open.

> You're just talking about textual issues here, there's no semantic
> information about what any of this stuff does or how the changes relate
> to each other at all.
> 
>> When you applied 8fef626 you mentioned that it did not applied cleanly.
>> The reason was that the branch did not had commit d0db84e applied prior to the
>> series:
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/054668.html
> 
>> Now I can not find the d0db84e commit in the asoc tree (not in for-3.6, for-3.7
>> and not in for-next branch) anymore.
> 
> The above doesn't mean much to me.

So how can we resolve this?
Are you going to rebase or update your 3.7, for-next topic/omap branches on
mainline so they will contain the mainline patch (d0db84e)?
Not sure if I mentioned it but I have created a branch (for you to take, or
observe):
git://gitorious.org/omap-audio/linux-audio.git peter/topic/for-mark/omap-3.7

Here I have your topic/omap branch rebased on mainline and I have fixed the
commit 8fef626 and added the missing chunk in order to avoid build failure.

A patch against your 3.7, for-next, topic/omap will not apply in linux-next
and a patch on top of linux-next would not apply in the asoc tree.

Please let me know how can I help to resolve this - I do not want 3.7-rc1 to
be broken when it comes out for OMAP audio.

Thank you,
Péter