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

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

[Peter Ujfalusi]

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.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
Hi Mark,

This patch has been generated against linux-next as of today.
The reason for this is that that is the only place where we have the upstream
patch (in 3.6-rc3):
d0db84e ASoC: omap-mcbsp: Fix 6pin mux configuration

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

commit in the same branch.

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.

I don't really know what has happened, but as of now this patch is needed to fix
the OMAP audio in linux-next.

I have also prepared a branch with the OMAP patches [1]: topic/omap rebased on
top of today's mainline and fixed up the 8fef626 to it's original content.
But I think it is already late to revert the OMAP McBSP patches from for-next
and from for-3.7 branches...

[1] git://gitorious.org/omap-audio/linux-audio.git peter/topic/for-mark/omap-3.7

CC-ing linux-next as well.

Regards,
Peter

 sound/soc/omap/mcbsp.c | 31 -------------------------------
 1 file changed, 31 deletions(-)

diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
index 935ccf6..bc06175 100644
--- a/sound/soc/omap/mcbsp.c
+++ b/sound/soc/omap/mcbsp.c
@@ -762,37 +762,6 @@ int omap2_mcbsp_set_clks_src(struct omap_mcbsp *mcbsp, u8 fck_src_id)
 
 }
 
-int omap_mcbsp_6pin_src_mux(struct omap_mcbsp *mcbsp, u8 mux)
-{
-	const char *signal, *src;
-
-	if (!mcbsp->pdata->mux_signal)
-		return -EINVAL;
-
-	switch (mux) {
-	case CLKR_SRC_CLKR:
-		signal = "clkr";
-		src = "clkr";
-		break;
-	case CLKR_SRC_CLKX:
-		signal = "clkr";
-		src = "clkx";
-		break;
-	case FSR_SRC_FSR:
-		signal = "fsr";
-		src = "fsr";
-		break;
-	case FSR_SRC_FSX:
-		signal = "fsr";
-		src = "fsx";
-		break;
-	default:
-		return -EINVAL;
-	}
-
-	return mcbsp->pdata->mux_signal(mcbsp->dev, signal, src);
-}
-
 #define max_thres(m)			(mcbsp->pdata->buffer_size)
 #define valid_threshold(m, val)		((val) <= max_thres(m))
 #define THRESHOLD_PROP_BUILDER(prop)					\
-- 
1.7.12

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

[Mark Brown]

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?
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.

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

[Peter Ujfalusi]

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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

Hi Peter,

On Thu, 30 Aug 2012 17:06:15 +0300 Peter Ujfalusi <peter.ujfalusi@ti.com> 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.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

I used this as a merge fix patch when I merged the sound-asoc tree today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Mark Brown]

On Mon, Sep 03, 2012 at 11:56:21AM +0300, Peter Ujfalusi wrote:

> 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)?

So, I think I figured out what you're talking about here.  Check -next.
Please if you're going to do stuff like this in future:

 - Talk about the actual code we've got.  It's OK to explain the history
   but it's very important to explain the concrete problem - that was
   missing from your mails (the closest we got was "compilation problem").

 - Discuss changes to what's there, starting off with "let's throw
   everything away" doesn't help with clarity especially with a missing
   problem description.

The problem description is especially critical.