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;
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?
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
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.
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
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.
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.
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.
-
Kuninori Morimoto -
Mark Brown -
Paul Mundt