linux-next: manual merge of the sound-asoc tree with the i.MX tree

linux-next: manual merge of the sound-asoc tree with the i.MX tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the sound-asoc tree got a conflict in
arch/arm/mach-mx3/devices.c between commit
4697bb926f43b8012ebd111ef43834f42126a0ef ("ARM: imx: dynamically allocate
imx-ssi devices") from the i.MX tree and commit
f0fba2ad1b6b53d5360125c41953b7afcd6deff0 ("ASoC: multi-component - ASoC
Multi-Component Support") from the sound-asoc tree.

The former removed that code that the latter changed.  I just used the
former.

The latter was just changing some names, so ti may be able to be
integrated into the former.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the sound-asoc tree with the i.MX tree

[Mark Brown]

On Thu, Sep 30, 2010 at 11:23:02AM +1000, Stephen Rothwell wrote:

> The former removed that code that the latter changed.  I just used the
> former.

> The latter was just changing some names, so ti may be able to be
> integrated into the former.

Though doing that would break bisection.  The other option would be to
revert the bit of the multi-component change that does the rename which
I think should be safe - Sacha, Liam, does that seem sensible?  There is
the issue with other potential non-audio users of the SSI to be
considered.

Re: linux-next: manual merge of the sound-asoc tree with the i.MX tree

[Uwe Kleine-König]

On Thu, Sep 30, 2010 at 11:23:02AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the sound-asoc tree got a conflict in
> arch/arm/mach-mx3/devices.c between commit
> 4697bb926f43b8012ebd111ef43834f42126a0ef ("ARM: imx: dynamically allocate
> imx-ssi devices") from the i.MX tree and commit
> f0fba2ad1b6b53d5360125c41953b7afcd6deff0 ("ASoC: multi-component - ASoC
> Multi-Component Support") from the sound-asoc tree.
> 
> The former removed that code that the latter changed.  I just used the
> former.
> 
> The latter was just changing some names, so ti may be able to be
> integrated into the former.
I think the same problem exists for mx2.  Maybe git didn't notice as
arch/arm/mach-mx2/devices.c was moved to arch/arm/mach-imx/devices.c
(and merged with arch/arm/mach-mx1/devices.c)?!

I didn't test, but I guess we need the following patch squashed into the
merge:

diff --git a/arch/arm/plat-mxc/devices/platform-imx-ssi.c b/arch/arm/plat-mxc/devices/platform-imx-ssi.c
index 38a7a0b..6d74a25 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-ssi.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-ssi.c
@@ -101,7 +101,7 @@ struct platform_device *__init imx_add_imx_ssi(
 		DMARES(rx1),
 	};
 
-	return imx_add_platform_device("imx-ssi", data->id,
+	return imx_add_platform_device("imx-ssi-dai", data->id,
 			res, ARRAY_SIZE(res),
 			pdata, sizeof(*pdata));
 }

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: linux-next: manual merge of the sound-asoc tree with the i.MX tree

[Uwe Kleine-König]

On Wed, Sep 29, 2010 at 08:31:11PM -0700, Mark Brown wrote:
> On Thu, Sep 30, 2010 at 11:23:02AM +1000, Stephen Rothwell wrote:
> 
> > The former removed that code that the latter changed.  I just used the
> > former.
> 
> > The latter was just changing some names, so ti may be able to be
> > integrated into the former.
> 
> Though doing that would break bisection.  The other option would be to
> revert the bit of the multi-component change that does the rename which
> I think should be safe - Sacha, Liam, does that seem sensible?  There is
> the issue with other potential non-audio users of the SSI to be
> considered.
I might be wrong, but I think there are no non-audio users of the ssi
device?

I think the correct fix is to squash the patch I just sent into the
commit merging the two.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: linux-next: manual merge of the sound-asoc tree with the i.MX tree

[Uwe Kleine-König]

Hello,

On Thu, Sep 30, 2010 at 08:41:40AM +0200, Uwe Kleine-König wrote:
> On Thu, Sep 30, 2010 at 11:23:02AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the sound-asoc tree got a conflict in
> > arch/arm/mach-mx3/devices.c between commit
> > 4697bb926f43b8012ebd111ef43834f42126a0ef ("ARM: imx: dynamically allocate
> > imx-ssi devices") from the i.MX tree and commit
> > f0fba2ad1b6b53d5360125c41953b7afcd6deff0 ("ASoC: multi-component - ASoC
> > Multi-Component Support") from the sound-asoc tree.
> > 
> > The former removed that code that the latter changed.  I just used the
> > former.
> > 
> > The latter was just changing some names, so ti may be able to be
> > integrated into the former.
> I think the same problem exists for mx2.  Maybe git didn't notice as
> arch/arm/mach-mx2/devices.c was moved to arch/arm/mach-imx/devices.c
> (and merged with arch/arm/mach-mx1/devices.c)?!
> 
> I didn't test, but I guess we need the following patch squashed into the
> merge:
> 
> diff --git a/arch/arm/plat-mxc/devices/platform-imx-ssi.c b/arch/arm/plat-mxc/devices/platform-imx-ssi.c
> index 38a7a0b..6d74a25 100644
> --- a/arch/arm/plat-mxc/devices/platform-imx-ssi.c
> +++ b/arch/arm/plat-mxc/devices/platform-imx-ssi.c
> @@ -101,7 +101,7 @@ struct platform_device *__init imx_add_imx_ssi(
>  		DMARES(rx1),
>  	};
>  
> -	return imx_add_platform_device("imx-ssi", data->id,
> +	return imx_add_platform_device("imx-ssi-dai", data->id,
>  			res, ARRAY_SIZE(res),
>  			pdata, sizeof(*pdata));
>  }
I just noticed there are some more problems:

	ukl@octopus:~/gsrc/linux-2.6$ git grep \"imx-ssi[^-] next/master -- arch/arm/mach-{imx,mx*}
	next/master:arch/arm/mach-imx/clock-imx27.c:    _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk)
	next/master:arch/arm/mach-imx/clock-imx27.c:    _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk)
	next/master:arch/arm/mach-mx25/clock.c: _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk)
	next/master:arch/arm/mach-mx25/clock.c: _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk)
	next/master:arch/arm/mach-mx5/clock-mx51.c:     _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk)
	next/master:arch/arm/mach-mx5/clock-mx51.c:     _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk)

The change to clock-imx27.c got lost similar to mx2/devices.c.  When
f0fba2ad1b6b53d5360125c41953b7afcd6deff0 was commited
arch/arm/mach-mx5/clock-mx51.c and arch/arm/mach-mx25/clock.c didn't
contain the clock for imx-ssi, yet.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: linux-next: manual merge of the sound-asoc tree with the i.MX tree

[Mark Brown]

On Thu, Sep 30, 2010 at 08:45:33AM +0200, Uwe Kleine-König wrote:

> I might be wrong, but I think there are no non-audio users of the ssi
> device?

That's kind of the point; while this is a generic serial port I've never
seen it used for anything except audio.

> I think the correct fix is to squash the patch I just sent into the
> commit merging the two.

If there's no non-audio users there's no need to do the rename - the
renames are to avoid having the ASoC DAI drivers suddenly start binding
with other drivers so we could just revert the rename in ASoC which
would remove the merge issue.

Re: linux-next: manual merge of the sound-asoc tree with the i.MX tree

[Uwe Kleine-König]

On Wed, Sep 29, 2010 at 11:58:13PM -0700, Mark Brown wrote:
> On Thu, Sep 30, 2010 at 08:45:33AM +0200, Uwe Kleine-König wrote:
> 
> > I might be wrong, but I think there are no non-audio users of the ssi
> > device?
> 
> That's kind of the point; while this is a generic serial port I've never
> seen it used for anything except audio.
> 
> > I think the correct fix is to squash the patch I just sent into the
> > commit merging the two.
> 
> If there's no non-audio users there's no need to do the rename - the
> renames are to avoid having the ASoC DAI drivers suddenly start binding
> with other drivers so we could just revert the rename in ASoC which
> would remove the merge issue.
Ah, now I got your point.  Your suggestion to keep the name for now
(until maybe in the future we get other users) sounds sensible.

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |