linux-next: manual merge of the sound tree with the arm-soc tree

linux-next: manual merge of the sound tree with the arm-soc tree

[Stephen Rothwell]

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

Hi Takashi,

Today's linux-next merge of the sound tree got conflicts in:

  arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
  arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi

between commits:

  5eef17ee764d ("arm64: tegra: p2972: Sort nodes properly")
  be4f0dd347ad ("arm64: tegra: p2597: Sort nodes by unit-address")

from the arm-soc tree and commit:

  11ce4308307c ("arm64: tegra: custom name for hda sound card")

from the sound tree.

I fixed it up (see below - in tegra194-p2972-0000.dts. the line added
just needed to be moved up a few lines) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
index 34a7044927fd,39c616737232..000000000000
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
diff --cc arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
index 8780b5b3d2b9,6096dfb7e17a..000000000000
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
@@@ -1317,15 -1303,6 +1317,16 @@@
  		clock-frequency = <100000>;
  	};
  
 +	sata@70020000 {
 +		status = "okay";
 +		phys = <&{/padctl@7009f000/pads/sata/lanes/sata-0}>;
 +	};
 +
 +	hda@70030000 {
++		nvidia,model = "jetson-tx1-hda";
 +		status = "okay";
 +	};
 +
  	usb@70090000 {
  		phys = <&{/padctl@7009f000/pads/usb2/lanes/usb2-0}>,
  		       <&{/padctl@7009f000/pads/usb2/lanes/usb2-1}>,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the sound tree with the arm-soc tree

[Arnd Bergmann]

On Mon, Feb 25, 2019 at 2:36 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Takashi,
>
> Today's linux-next merge of the sound tree got conflicts in:
>
>   arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
>   arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
>
> between commits:
>
>   5eef17ee764d ("arm64: tegra: p2972: Sort nodes properly")
>   be4f0dd347ad ("arm64: tegra: p2597: Sort nodes by unit-address")
>
> from the arm-soc tree and commit:
>
>   11ce4308307c ("arm64: tegra: custom name for hda sound card")
>
> from the sound tree.
>
> I fixed it up (see below - in tegra194-p2972-0000.dts. the line added
> just needed to be moved up a few lines) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

The merge looks fine to me, but I wonder about that commit
in the alsa tree, why does the sound card need a board specific
name?

I see this property being used in commit c0bde003a013 ("ALSA:
hda/tegra: sound card name from device tree"), which removes
a questionable use of the root compatible property, replacing
it with the new 'nvidia,model' property. We don't do this for any
other subsystem, so why does the sound subsystem export
information about the board as a string here?

(added ASoC maintainers to Cc for insight).

      Arnd

Re: linux-next: manual merge of the sound tree with the arm-soc tree

[Takashi Iwai]

On Mon, 25 Feb 2019 10:19:15 +0100,
Arnd Bergmann wrote:
> 
> On Mon, Feb 25, 2019 at 2:36 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi Takashi,
> >
> > Today's linux-next merge of the sound tree got conflicts in:
> >
> >   arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
> >   arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
> >
> > between commits:
> >
> >   5eef17ee764d ("arm64: tegra: p2972: Sort nodes properly")
> >   be4f0dd347ad ("arm64: tegra: p2597: Sort nodes by unit-address")
> >
> > from the arm-soc tree and commit:
> >
> >   11ce4308307c ("arm64: tegra: custom name for hda sound card")
> >
> > from the sound tree.
> >
> > I fixed it up (see below - in tegra194-p2972-0000.dts. the line added
> > just needed to be moved up a few lines) and can carry the fix as
> > necessary. This is now fixed as far as linux-next is concerned, but any
> > non trivial conflicts should be mentioned to your upstream maintainer
> > when your tree is submitted for merging.  You may also want to consider
> > cooperating with the maintainer of the conflicting tree to minimise any
> > particularly complex conflicts.
> 
> The merge looks fine to me, but I wonder about that commit
> in the alsa tree, why does the sound card need a board specific
> name?
> 
> I see this property being used in commit c0bde003a013 ("ALSA:
> hda/tegra: sound card name from device tree"), which removes
> a questionable use of the root compatible property, replacing
> it with the new 'nvidia,model' property. We don't do this for any
> other subsystem, so why does the sound subsystem export
> information about the board as a string here?

The sound subsystem exports merely some understandable name string
for the given sound card object, and that was composed from the
compatible string in the past, which turned out to be useless on some
configs.

But this kind of addition is an extremely bad manner, I'm fine to
revert these (at best with a better alternative).  This isn't about
any functionality but rather some readable information that isn't a
part of API.


thanks,

Takashi

Re: linux-next: manual merge of the sound tree with the arm-soc tree

[Sameer Pujar]

On 2/25/2019 4:44 PM, Takashi Iwai wrote:
> On Mon, 25 Feb 2019 10:19:15 +0100,
> Arnd Bergmann wrote:
>> On Mon, Feb 25, 2019 at 2:36 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> Hi Takashi,
>>>
>>> Today's linux-next merge of the sound tree got conflicts in:
>>>
>>>    arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
>>>    arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
>>>
>>> between commits:
>>>
>>>    5eef17ee764d ("arm64: tegra: p2972: Sort nodes properly")
>>>    be4f0dd347ad ("arm64: tegra: p2597: Sort nodes by unit-address")
>>>
>>> from the arm-soc tree and commit:
>>>
>>>    11ce4308307c ("arm64: tegra: custom name for hda sound card")
>>>
>>> from the sound tree.
>>>
>>> I fixed it up (see below - in tegra194-p2972-0000.dts. the line added
>>> just needed to be moved up a few lines) and can carry the fix as
>>> necessary. This is now fixed as far as linux-next is concerned, but any
>>> non trivial conflicts should be mentioned to your upstream maintainer
>>> when your tree is submitted for merging.  You may also want to consider
>>> cooperating with the maintainer of the conflicting tree to minimise any
>>> particularly complex conflicts.
>> The merge looks fine to me, but I wonder about that commit
>> in the alsa tree, why does the sound card need a board specific
>> name?
>>
>> I see this property being used in commit c0bde003a013 ("ALSA:
>> hda/tegra: sound card name from device tree"), which removes
>> a questionable use of the root compatible property, replacing
>> it with the new 'nvidia,model' property. We don't do this for any
>> other subsystem, so why does the sound subsystem export
>> information about the board as a string here?
> The sound subsystem exports merely some understandable name string
> for the given sound card object, and that was composed from the
> compatible string in the past, which turned out to be useless on some
> configs.
>
> But this kind of addition is an extremely bad manner, I'm fine to
> revert these (at best with a better alternative).  This isn't about
> any functionality but rather some readable information that isn't a
> part of API.
>
The motivation for adding custom sound card name is following,
1. When for boards, multiple HDMI/DP ports are exposed, it is sometimes
    necessary to know the default port or any customization for that matter.
    Audio userspace can distinguish based on the sound card names.
2. Multiple sound cards can coexist for a platform, the indication of 
particular
    audio path is useful.
3. It can help to customize audio paths.
    Generally people use "*,model" property in DT to name the sound complex.
    Ex: "samsung,model" [sound/soc/samsung/snow.c]
        "rockchip,model" [sound/soc/rockchip/rockchip_rt5645.c]

Thanks,
Sameer.
> thanks,
>
> Takashi

Re: linux-next: manual merge of the sound tree with the arm-soc tree

[Arnd Bergmann]

On Mon, Feb 25, 2019 at 12:24 PM Sameer Pujar <spujar@nvidia.com> wrote:
> On 2/25/2019 4:44 PM, Takashi Iwai wrote:
> > On Mon, 25 Feb 2019 10:19:15 +0100, Arnd Bergmann wrote:
> >> On Mon, Feb 25, 2019 at 2:36 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> I see this property being used in commit c0bde003a013 ("ALSA:
> >> hda/tegra: sound card name from device tree"), which removes
> >> a questionable use of the root compatible property, replacing
> >> it with the new 'nvidia,model' property. We don't do this for any
> >> other subsystem, so why does the sound subsystem export
> >> information about the board as a string here?
> > The sound subsystem exports merely some understandable name string
> > for the given sound card object, and that was composed from the
> > compatible string in the past, which turned out to be useless on some
> > configs.
> >
> > But this kind of addition is an extremely bad manner, I'm fine to
> > revert these (at best with a better alternative).  This isn't about
> > any functionality but rather some readable information that isn't a
> > part of API.

It is not extremely bad, but it is at the minimum surprising.

> The motivation for adding custom sound card name is following,
> 1. When for boards, multiple HDMI/DP ports are exposed, it is sometimes
>     necessary to know the default port or any customization for that matter.
>     Audio userspace can distinguish based on the sound card names.
> 2. Multiple sound cards can coexist for a platform, the indication of
> particular
>     audio path is useful.
> 3. It can help to customize audio paths.
>     Generally people use "*,model" property in DT to name the sound complex.
>     Ex: "samsung,model" [sound/soc/samsung/snow.c]
>         "rockchip,model" [sound/soc/rockchip/rockchip_rt5645.c]

I see, I had not noticed those before. They do seem a little unusual,
and inconsistent, as the samsung sames are always names the board
there, but rockchip doesn't: one board names it just "I2C", the other
one uses "VEYRON-I2S", and the example in the documentation lists
"ROCKCHIP-I2S" and "Analog audio output", each of them following
different naming systems.

In Documentation/devicetree/bindings/sound/qcom,apq8096.txt, a
"qcom,model" property is listeds as "Obsolete", and replaced by
a "model" property. This is in turn also used on amlogic, freescale,
and some samsung platforms.

My impression here is that the idea of passing a model name
through DT is well established, but for new stuff, we probably
want to standardize on plain "model" rather than "$vendor,model".

       Arnd

Re: linux-next: manual merge of the sound tree with the arm-soc tree

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1313 bytes --]

On Mon, Feb 25, 2019 at 02:38:50PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 25, 2019 at 12:24 PM Sameer Pujar <spujar@nvidia.com> wrote:

> > The motivation for adding custom sound card name is following,
> > 1. When for boards, multiple HDMI/DP ports are exposed, it is sometimes
> >     necessary to know the default port or any customization for that matter.
> >     Audio userspace can distinguish based on the sound card names.
> > 2. Multiple sound cards can coexist for a platform, the indication of
> > particular
> >     audio path is useful.
> > 3. It can help to customize audio paths.
> >     Generally people use "*,model" property in DT to name the sound complex.
> >     Ex: "samsung,model" [sound/soc/samsung/snow.c]
> >         "rockchip,model" [sound/soc/rockchip/rockchip_rt5645.c]

It's also useful since sound cards can be electically identical but
prefer different configuration due to the plastics (eg, a smaller
speaker was fitted, different outputs have different labels or playing
the speaker at full volume causes some models to have unpleasant effects
while others handle it fine).

> My impression here is that the idea of passing a model name
> through DT is well established, but for new stuff, we probably
> want to standardize on plain "model" rather than "$vendor,model".

Yes.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

linux-next: manual merge of the sound tree with the arm-soc tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the sound tree got a conflict in:

  sound/soc/cirrus/edb93xx.c

between commit:

  7a9a9110d765 ("ASoC: cirrus: edb93xx: Delete driver")

from the arm-soc tree and commit:

  130af75b5c05 ("ASoC: Switch back to struct platform_driver::remove()")

from the sound tree.

I fixed it up (I removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the sound tree with the arm-soc tree

[Uwe Kleine-König]

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

Hello Stephen,

On Mon, Sep 16, 2024 at 02:58:00PM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the sound tree got a conflict in:
> 
>   sound/soc/cirrus/edb93xx.c
> 
> between commit:
> 
>   7a9a9110d765 ("ASoC: cirrus: edb93xx: Delete driver")
> 
> from the arm-soc tree and commit:
> 
>   130af75b5c05 ("ASoC: Switch back to struct platform_driver::remove()")
> 
> from the sound tree.
> 
> I fixed it up (I removed the file) and can carry the fix as
> necessary.

JFTR: I didn't check your tree, but that sounds like the right
resolution.

Thanks for your effort to run linux-next!
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the sound tree with the arm-soc tree

[Stephen Rothwell]

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

Hi all,

On Mon, 16 Sep 2024 14:58:00 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the sound tree got a conflict in:
> 
>   sound/soc/cirrus/edb93xx.c
> 
> between commit:
> 
>   7a9a9110d765 ("ASoC: cirrus: edb93xx: Delete driver")
> 
> from the arm-soc tree and commit:
> 
>   130af75b5c05 ("ASoC: Switch back to struct platform_driver::remove()")
> 
> from the sound tree.
> 
> I fixed it up (I removed the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

This is now a conflict between the arm-soc tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the sound tree with the arm-soc tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the sound tree got conflicts in:

  sound/soc/cirrus/ep93xx-ac97.c
  sound/soc/pxa/e740_wm9705.c
  sound/soc/pxa/e750_wm9705.c
  sound/soc/pxa/e800_wm9712.c
  sound/soc/ti/davinci-vcif.c

between commits:

  2b45e1fa9398 ("ASoC: remove unused ep93xx files")
  efe81e9a9273 ("ASoC: remove unused davinci support")
  b401d1fd8053 ("ASoC: pxa: remove unused board support")

from the arm-soc tree and commits:

  f2211ac36ab0 ("ASoC: pxa: e740_wm9705: Drop empty platform remove function")
  4ed923e8076b ("ASoC: pxa: e750_wm9705: Drop empty platform remove function")
  394296eee2c2 ("ASoC: pxa: e800_wm9712: Drop empty platform remove function")
  0e478b88b257 ("ASoC: cirrus: use helper function")
  2abde57fb82b ("ASoC: ti: use helper function")

from the sound tree.

I fixed it up (I just removed the files) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the sound tree with the arm-soc tree

[Stephen Rothwell]

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

Hi all,

On Fri, 17 Feb 2023 11:23:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the sound tree got conflicts in:
> 
>   sound/soc/cirrus/ep93xx-ac97.c
>   sound/soc/pxa/e740_wm9705.c
>   sound/soc/pxa/e750_wm9705.c
>   sound/soc/pxa/e800_wm9712.c
>   sound/soc/ti/davinci-vcif.c
> 
> between commits:
> 
>   2b45e1fa9398 ("ASoC: remove unused ep93xx files")
>   efe81e9a9273 ("ASoC: remove unused davinci support")
>   b401d1fd8053 ("ASoC: pxa: remove unused board support")
> 
> from the arm-soc tree and commits:
> 
>   f2211ac36ab0 ("ASoC: pxa: e740_wm9705: Drop empty platform remove function")
>   4ed923e8076b ("ASoC: pxa: e750_wm9705: Drop empty platform remove function")
>   394296eee2c2 ("ASoC: pxa: e800_wm9712: Drop empty platform remove function")
>   0e478b88b257 ("ASoC: cirrus: use helper function")
>   2abde57fb82b ("ASoC: ti: use helper function")
> 
> from the sound tree.
> 
> I fixed it up (I just removed the files) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

This is now a conflict between the arm-soc tree and the
sound-asoc-fixes tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the sound tree with the arm-soc tree

[Stephen Rothwell]

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

Hi all,

On Tue, 21 Feb 2023 09:27:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> On Fri, 17 Feb 2023 11:23:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the sound tree got conflicts in:
> > 
> >   sound/soc/cirrus/ep93xx-ac97.c
> >   sound/soc/pxa/e740_wm9705.c
> >   sound/soc/pxa/e750_wm9705.c
> >   sound/soc/pxa/e800_wm9712.c
> >   sound/soc/ti/davinci-vcif.c
> > 
> > between commits:
> > 
> >   2b45e1fa9398 ("ASoC: remove unused ep93xx files")
> >   efe81e9a9273 ("ASoC: remove unused davinci support")
> >   b401d1fd8053 ("ASoC: pxa: remove unused board support")
> > 
> > from the arm-soc tree and commits:
> > 
> >   f2211ac36ab0 ("ASoC: pxa: e740_wm9705: Drop empty platform remove function")
> >   4ed923e8076b ("ASoC: pxa: e750_wm9705: Drop empty platform remove function")
> >   394296eee2c2 ("ASoC: pxa: e800_wm9712: Drop empty platform remove function")
> >   0e478b88b257 ("ASoC: cirrus: use helper function")
> >   2abde57fb82b ("ASoC: ti: use helper function")
> > 
> > from the sound tree.
> > 
> > I fixed it up (I just removed the files) and can carry the fix as
> > necessary. This is now fixed as far as linux-next is concerned, but any
> > non trivial conflicts should be mentioned to your upstream maintainer
> > when your tree is submitted for merging.  You may also want to consider
> > cooperating with the maintainer of the conflicting tree to minimise any
> > particularly complex conflicts.  
> 
> This is now a conflict between the arm-soc tree and the
> sound-asoc-fixes tree.

This is now a conflict between the sound-asoc-fixes tree and Linus'
tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the sound tree with the arm-soc tree

[Stephen Rothwell]

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

Hi Takashi,

Today's linux-next merge of the sound tree got a conflict in
arch/arm/plat-omap/devices.c between commit 40246e0003f0 ("ARM: OMAP:
mcbsp: Move out omap_mcbsp_register_board_cfg from plat-omap/devices")
from the arm-soc tree and commit d231f5cbac9e ("OMAP: McPDM: Convert
McPDM device to omap_device") from the sound tree.

Just overlapping removals.  I fixed it up (see below) and can carry the
fix as necessary.

Mark, Liam:  That sound tree commit has a few Signed-off-by lines with no
email addresses.

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

diff --cc arch/arm/plat-omap/devices.c
index acd132c,40eca9b..0000000
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@@ -24,44 -24,56 +24,11 @@@
  #include <plat/tc.h>
  #include <plat/board.h>
  #include <plat/mmc.h>
 -#include <mach/gpio.h>
  #include <plat/menelaus.h>
 -#include <plat/mcbsp.h>
  #include <plat/omap44xx.h>
  
- #if defined(CONFIG_SND_OMAP_SOC_MCPDM) || \
- 		defined(CONFIG_SND_OMAP_SOC_MCPDM_MODULE)
- 
- static struct resource mcpdm_resources[] = {
- 	{
- 		.name		= "mcpdm_mem",
- 		.start		= OMAP44XX_MCPDM_BASE,
- 		.end		= OMAP44XX_MCPDM_BASE + SZ_4K,
- 		.flags		= IORESOURCE_MEM,
- 	},
- 	{
- 		.name		= "mcpdm_irq",
- 		.start		= OMAP44XX_IRQ_MCPDM,
- 		.end		= OMAP44XX_IRQ_MCPDM,
- 		.flags		= IORESOURCE_IRQ,
- 	},
- };
- 
- static struct platform_device omap_mcpdm_device = {
- 	.name		= "omap-mcpdm",
- 	.id		= -1,
- 	.num_resources	= ARRAY_SIZE(mcpdm_resources),
- 	.resource	= mcpdm_resources,
- };
- 
- static void omap_init_mcpdm(void)
- {
- 	(void) platform_device_register(&omap_mcpdm_device);
- }
- #else
- static inline void omap_init_mcpdm(void) {}
- #endif
- 
  /*-------------------------------------------------------------------------*/
  
 -#if defined(CONFIG_OMAP_MCBSP) || defined(CONFIG_OMAP_MCBSP_MODULE)
 -
 -static struct platform_device **omap_mcbsp_devices;
 -
 -void omap_mcbsp_register_board_cfg(struct resource *res, int res_count,
 -			struct omap_mcbsp_platform_data *config, int size)
 -{
 -	int i;
 -
 -	omap_mcbsp_devices = kzalloc(size * sizeof(struct platform_device *),
 -				     GFP_KERNEL);
 -	if (!omap_mcbsp_devices) {
 -		printk(KERN_ERR "Could not register McBSP devices\n");
 -		return;
 -	}
 -
 -	for (i = 0; i < size; i++) {
 -		struct platform_device *new_mcbsp;
 -		int ret;
 -
 -		new_mcbsp = platform_device_alloc("omap-mcbsp", i + 1);
 -		if (!new_mcbsp)
 -			continue;
 -		platform_device_add_resources(new_mcbsp, &res[i * res_count],
 -					res_count);
 -		new_mcbsp->dev.platform_data = &config[i];
 -		ret = platform_device_add(new_mcbsp);
 -		if (ret) {
 -			platform_device_put(new_mcbsp);
 -			continue;
 -		}
 -		omap_mcbsp_devices[i] = new_mcbsp;
 -	}
 -}
 -
 -#else
 -void omap_mcbsp_register_board_cfg(struct resource *res, int res_count,
 -			struct omap_mcbsp_platform_data *config, int size)
 -{  }
 -#endif
 -
 -/*-------------------------------------------------------------------------*/
 -
  #if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
  	defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
  

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

Re: linux-next: manual merge of the sound tree with the arm-soc tree

[Ujfalusi, Peter]

Hi Stephen,

On Tue, Oct 11, 2011 at 7:43 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Takashi,
>
> Today's linux-next merge of the sound tree got a conflict in
> arch/arm/plat-omap/devices.c between commit 40246e0003f0 ("ARM: OMAP:
> mcbsp: Move out omap_mcbsp_register_board_cfg from plat-omap/devices")
> from the arm-soc tree and commit d231f5cbac9e ("OMAP: McPDM: Convert
> McPDM device to omap_device") from the sound tree.
>
> Just overlapping removals.  I fixed it up (see below) and can carry the
> fix as necessary.

Thanks, the McBSP change came via linux-omap while we had the McPDM
changes coming via sound tree.

>
> Mark, Liam:  That sound tree commit has a few Signed-off-by lines with no
> email addresses.

I can not track their new contact information. They used to work for TI, and I
have been advised to give them credit for their work on this area.
I could have added no longer valid email addresses...

-- 
Péter

> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
>
> diff --cc arch/arm/plat-omap/devices.c
> index acd132c,40eca9b..0000000
> --- a/arch/arm/plat-omap/devices.c
> +++ b/arch/arm/plat-omap/devices.c
> @@@ -24,44 -24,56 +24,11 @@@
>  #include <plat/tc.h>
>  #include <plat/board.h>
>  #include <plat/mmc.h>
>  -#include <mach/gpio.h>
>  #include <plat/menelaus.h>
>  -#include <plat/mcbsp.h>
>  #include <plat/omap44xx.h>
>
> - #if defined(CONFIG_SND_OMAP_SOC_MCPDM) || \
> -               defined(CONFIG_SND_OMAP_SOC_MCPDM_MODULE)
> -
> - static struct resource mcpdm_resources[] = {
> -       {
> -               .name           = "mcpdm_mem",
> -               .start          = OMAP44XX_MCPDM_BASE,
> -               .end            = OMAP44XX_MCPDM_BASE + SZ_4K,
> -               .flags          = IORESOURCE_MEM,
> -       },
> -       {
> -               .name           = "mcpdm_irq",
> -               .start          = OMAP44XX_IRQ_MCPDM,
> -               .end            = OMAP44XX_IRQ_MCPDM,
> -               .flags          = IORESOURCE_IRQ,
> -       },
> - };
> -
> - static struct platform_device omap_mcpdm_device = {
> -       .name           = "omap-mcpdm",
> -       .id             = -1,
> -       .num_resources  = ARRAY_SIZE(mcpdm_resources),
> -       .resource       = mcpdm_resources,
> - };
> -
> - static void omap_init_mcpdm(void)
> - {
> -       (void) platform_device_register(&omap_mcpdm_device);
> - }
> - #else
> - static inline void omap_init_mcpdm(void) {}
> - #endif
> -
>  /*-------------------------------------------------------------------------*/
>
>  -#if defined(CONFIG_OMAP_MCBSP) || defined(CONFIG_OMAP_MCBSP_MODULE)
>  -
>  -static struct platform_device **omap_mcbsp_devices;
>  -
>  -void omap_mcbsp_register_board_cfg(struct resource *res, int res_count,
>  -                      struct omap_mcbsp_platform_data *config, int size)
>  -{
>  -      int i;
>  -
>  -      omap_mcbsp_devices = kzalloc(size * sizeof(struct platform_device *),
>  -                                   GFP_KERNEL);
>  -      if (!omap_mcbsp_devices) {
>  -              printk(KERN_ERR "Could not register McBSP devices\n");
>  -              return;
>  -      }
>  -
>  -      for (i = 0; i < size; i++) {
>  -              struct platform_device *new_mcbsp;
>  -              int ret;
>  -
>  -              new_mcbsp = platform_device_alloc("omap-mcbsp", i + 1);
>  -              if (!new_mcbsp)
>  -                      continue;
>  -              platform_device_add_resources(new_mcbsp, &res[i * res_count],
>  -                                      res_count);
>  -              new_mcbsp->dev.platform_data = &config[i];
>  -              ret = platform_device_add(new_mcbsp);
>  -              if (ret) {
>  -                      platform_device_put(new_mcbsp);
>  -                      continue;
>  -              }
>  -              omap_mcbsp_devices[i] = new_mcbsp;
>  -      }
>  -}
>  -
>  -#else
>  -void omap_mcbsp_register_board_cfg(struct resource *res, int res_count,
>  -                      struct omap_mcbsp_platform_data *config, int size)
>  -{  }
>  -#endif
>  -
>  -/*-------------------------------------------------------------------------*/
>  -
>  #if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
>        defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
>
>