[PATCH] ASoC: fsi-ak4642: Remove ak4642_add_i2c_device

[PATCH] ASoC: fsi-ak4642: Remove ak4642_add_i2c_device

[Kuninori Morimoto]

I2C devices should be registered when platform board setting
in latest ASoC.

Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
---
 sound/soc/sh/fsi-ak4642.c |   30 ------------------------------
 1 files changed, 0 insertions(+), 30 deletions(-)

diff --git a/sound/soc/sh/fsi-ak4642.c b/sound/soc/sh/fsi-ak4642.c
index c7af097..5263ab1 100644
--- a/sound/soc/sh/fsi-ak4642.c
+++ b/sound/soc/sh/fsi-ak4642.c
@@ -42,42 +42,12 @@ static struct snd_soc_device fsi_snd_devdata = {
 	.codec_dev	= &soc_codec_dev_ak4642,
 };
 
-#define AK4642_BUS 0
-#define AK4642_ADR 0x12
-static int ak4642_add_i2c_device(void)
-{
-	struct i2c_board_info info;
-	struct i2c_adapter *adapter;
-	struct i2c_client *client;
-
-	memset(&info, 0, sizeof(struct i2c_board_info));
-	info.addr = AK4642_ADR;
-	strlcpy(info.type, "ak4642", I2C_NAME_SIZE);
-
-	adapter = i2c_get_adapter(AK4642_BUS);
-	if (!adapter) {
-		printk(KERN_DEBUG "can't get i2c adapter\n");
-		return -ENODEV;
-	}
-
-	client = i2c_new_device(adapter, &info);
-	i2c_put_adapter(adapter);
-	if (!client) {
-		printk(KERN_DEBUG "can't add i2c device\n");
-		return -ENODEV;
-	}
-
-	return 0;
-}
-
 static struct platform_device *fsi_snd_device;
 
 static int __init fsi_ak4642_init(void)
 {
 	int ret = -ENOMEM;
 
-	ak4642_add_i2c_device();
-
 	fsi_snd_device = platform_device_alloc("soc-audio", -1);
 	if (!fsi_snd_device)
 		goto out;
-- 
1.6.3.3

Re: [PATCH] ASoC: fsi-ak4642: Remove ak4642_add_i2c_device

[Mark Brown]

On Mon, Dec 14, 2009 at 01:22:04PM +0900, Kuninori Morimoto wrote:
> I2C devices should be registered when platform board setting
> in latest ASoC.

> Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>

It'd be better to do a single patch which updates both ASoC and MIPS
trees simultaneously in order to ensure that bisection continues to
work.  Of course, if the MIPS side has been updated separately then we
should just apply this code - has that happened?

Re: [PATCH] ASoC: fsi-ak4642: Remove ak4642_add_i2c_device

[Kuninori Morimoto]

Dear Mark

> It'd be better to do a single patch which updates both ASoC and MIPS
> trees simultaneously in order to ensure that bisection continues to
> work.  Of course, if the MIPS side has been updated separately then we
> should just apply this code - has that happened?

Ohh.. sorry. My plan was sending patch to Paul (= SuperH)
I send this patch now.

Best regards
--
Kuninori Morimoto

Re: [PATCH] ASoC: fsi-ak4642: Remove ak4642_add_i2c_device

[Mark Brown]

On 15 Dec 2009, at 00:07, Kuninori Morimoto <morimoto.kuninori@renesas.com 
 > wrote:

>
> Dear Mark
>
>> It'd be better to do a single patch which updates both ASoC and MIPS
>> trees simultaneously in order to ensure that bisection continues to
>> work.  Of course, if the MIPS side has been updated separately then  
>> we
>> should just apply this code - has that happened?
>
> Ohh.. sorry. My plan was sending patch to Paul (= SuperH)
> I send this patch now.

No problem, feel free to add my ack to the combined patch.

Re: [PATCH] ASoC: fsi-ak4642: Remove ak4642_add_i2c_device

[Kuninori Morimoto]

Dear Mark

> >> It'd be better to do a single patch which updates both ASoC and MIPS
> >> trees simultaneously in order to ensure that bisection continues to
> >> work.  Of course, if the MIPS side has been updated separately then  
> >> we
> >> should just apply this code - has that happened?
> >
> > Ohh.. sorry. My plan was sending patch to Paul (= SuperH)
> > I send this patch now.
> 
> No problem, feel free to add my ack to the combined patch.

I sent patch which is for SuperH platform, and Paul already applied it.
I can find it on latest linus git (9f815a1765b0ce766ab1d26ef192d30410f70b2b).
So sorry, can you please re-check this email ?
[fsi-ak4642: Remove ak4642_add_i2c_device]

Best regards
--
Kuninori Morimoto

Re: [PATCH] ASoC: fsi-ak4642: Remove ak4642_add_i2c_device

[Mark Brown]

On Thu, Dec 24, 2009 at 03:11:43PM +0900, Kuninori Morimoto wrote:

> > No problem, feel free to add my ack to the combined patch.

> I sent patch which is for SuperH platform, and Paul already applied it.
> I can find it on latest linus git (9f815a1765b0ce766ab1d26ef192d30410f70b2b).
> So sorry, can you please re-check this email ?
> [fsi-ak4642: Remove ak4642_add_i2c_device]

Oh, what a shame.  I'll apply the patch.

Re: [PATCH] ASoC: fsi-ak4642: Remove ak4642_add_i2c_device

[Paul Mundt]

On Thu, Dec 24, 2009 at 11:40:18AM +0000, Mark Brown wrote:
> On Thu, Dec 24, 2009 at 03:11:43PM +0900, Kuninori Morimoto wrote:
> 
> > > No problem, feel free to add my ack to the combined patch.
> 
> > I sent patch which is for SuperH platform, and Paul already applied it.
> > I can find it on latest linus git (9f815a1765b0ce766ab1d26ef192d30410f70b2b).
> > So sorry, can you please re-check this email ?
> > [fsi-ak4642: Remove ak4642_add_i2c_device]
> 
> Oh, what a shame.  I'll apply the patch.

I missed the rest of this discussion, but if your conerns are about
bisection, it's not an issue in this case. Board patches that add i2c or
platform device data with no unmet dependencies I usually merge early.
The main rationale for this is that the driver often shows up quite a bit
later, and the board code will likely have had more paches piled up on
top of it and merge conflicts ensue.

For patches that depend on headers and definitions added by the driver
patch, we either apply them together, or I just hold off on the board
patch until the driver is upstream. patchwork helps keep track of the
ones that are still pending at least. These sorts of ordering issues
happen a lot, but are generally always resolved by rc2.

Re: [PATCH] ASoC: fsi-ak4642: Remove ak4642_add_i2c_device

[Mark Brown]

On Fri, Dec 25, 2009 at 09:45:02AM +0900, Paul Mundt wrote:

> I missed the rest of this discussion, but if your conerns are about
> bisection, it's not an issue in this case. Board patches that add i2c or
> platform device data with no unmet dependencies I usually merge early.
> The main rationale for this is that the driver often shows up quite a bit
> later, and the board code will likely have had more paches piled up on
> top of it and merge conflicts ensue.

What I was hoping for was a single patch which removed the existing code
within ASoC and added the matching arch code so that there wouldn't be
any versions which either had duplicate adds or missing adds.  There's
no build time dependency, only a runtime one.