[1/4] ASoC: rockchip: add rockchip machine driver
diff mbox

Message ID 1431422797-31903-2-git-send-email-zhengxing@rock-chips.com
State New
Headers show

Commit Message

Xing Zheng May 12, 2015, 9:26 a.m. UTC
From: zhengxing <zhengxing@rock-chips.com>

In most cases, we maybe use simple-card as generic machine driver
on next kernel, but there are some issue that jack detection and
widgets extandable on simple-card.

Own machine drvier can select one valid codec from supported codecs,
and add needful function from dts on rockchip platform.

Signed-off-by: zhengxing <zhengxing@rock-chips.com>
---

 sound/soc/rockchip/Kconfig                   |    7 +
 sound/soc/rockchip/Makefile                  |    5 +
 sound/soc/rockchip/rockchip_machine_driver.c |  210 ++++++++++++++++++++++++++
 sound/soc/rockchip/rockchip_machine_driver.h |   30 ++++
 4 files changed, 252 insertions(+)
 create mode 100644 sound/soc/rockchip/rockchip_machine_driver.c
 create mode 100644 sound/soc/rockchip/rockchip_machine_driver.h

Comments

Mark Brown May 12, 2015, 7:22 p.m. UTC | #1
On Tue, May 12, 2015 at 05:26:34PM +0800, Xing Zheng wrote:
> From: zhengxing <zhengxing@rock-chips.com>
> 
> In most cases, we maybe use simple-card as generic machine driver
> on next kernel, but there are some issue that jack detection and
> widgets extandable on simple-card.
> 
> Own machine drvier can select one valid codec from supported codecs,
> and add needful function from dts on rockchip platform.

Is it not possible to extend simple card to handle your use cases?
Given the very generic naming and the fact that things like jack
detection and so on should depend on the CODEC and board usually rather
than on the SoC it doesn't sound like this is Rockchip specific.

This also looks like you're reimplementing some device model enumeration
stuff which probably shouldn't be happening but let's understand the
problem you're trying to solve here before going too far into the code.
zhengxing May 13, 2015, 1:23 p.m. UTC | #2
On 2015?05?13? 03:22, Mark Brown wrote:
> On Tue, May 12, 2015 at 05:26:34PM +0800, Xing Zheng wrote:
>> From: zhengxing<zhengxing@rock-chips.com>
>>
>> In most cases, we maybe use simple-card as generic machine driver
>> on next kernel, but there are some issue that jack detection and
>> widgets extandable on simple-card.
>>
>> Own machine drvier can select one valid codec from supported codecs,
>> and add needful function from dts on rockchip platform.
> Is it not possible to extend simple card to handle your use cases?
> Given the very generic naming and the fact that things like jack
> detection and so on should depend on the CODEC and board usually rather
> than on the SoC it doesn't sound like this is Rockchip specific.
>
> This also looks like you're reimplementing some device model enumeration
> stuff which probably shouldn't be happening but let's understand the
> problem you're trying to solve here before going too far into the code.
Dear Mark,
Thanks for your reply.

Because we are trying to bring rt5650 in the project, so we intend to 
describe supported codecs with DTS via only a rockchip machine driver file,
others remain pre-implement(like max98090 / rt5645 that vendor machine 
driver).
I communicated with Dylan, and he told me that the jack detection is an 
issue in the simple-card, and suggested we are better to send them at 
present.

Thanks.
Mark Brown May 13, 2015, 4:42 p.m. UTC | #3
On Wed, May 13, 2015 at 09:23:01PM +0800, zhengxing wrote:
> On 2015?05?13? 03:22, Mark Brown wrote:

> >Is it not possible to extend simple card to handle your use cases?
> >Given the very generic naming and the fact that things like jack
> >detection and so on should depend on the CODEC and board usually rather
> >than on the SoC it doesn't sound like this is Rockchip specific.

> >This also looks like you're reimplementing some device model enumeration
> >stuff which probably shouldn't be happening but let's understand the
> >problem you're trying to solve here before going too far into the code.

> Because we are trying to bring rt5650 in the project, so we intend to
> describe supported codecs with DTS via only a rockchip machine driver file,
> others remain pre-implement(like max98090 / rt5645 that vendor machine
> driver).

I don't undertand what you're saying here, sorry - why is this not just
a case of writing multiple machine drivers?

> I communicated with Dylan, and he told me that the jack detection is an
> issue in the simple-card, and suggested we are better to send them at
> present.

But what are these issues?
Dylan Reid May 13, 2015, 5:21 p.m. UTC | #4
On Wed, May 13, 2015 at 9:42 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 13, 2015 at 09:23:01PM +0800, zhengxing wrote:
>> On 2015?05?13? 03:22, Mark Brown wrote:
>
>> >Is it not possible to extend simple card to handle your use cases?
>> >Given the very generic naming and the fact that things like jack
>> >detection and so on should depend on the CODEC and board usually rather
>> >than on the SoC it doesn't sound like this is Rockchip specific.
>
>> >This also looks like you're reimplementing some device model enumeration
>> >stuff which probably shouldn't be happening but let's understand the
>> >problem you're trying to solve here before going too far into the code.
>
>> Because we are trying to bring rt5650 in the project, so we intend to
>> describe supported codecs with DTS via only a rockchip machine driver file,
>> others remain pre-implement(like max98090 / rt5645 that vendor machine
>> driver).
>
> I don't undertand what you're saying here, sorry - why is this not just
> a case of writing multiple machine drivers?

I don't understand this either.  I'd think the best solution is
simple-card, configured through DTS for each device.

>
>> I communicated with Dylan, and he told me that the jack detection is an
>> issue in the simple-card, and suggested we are better to send them at
>> present.
>
> But what are these issues?

The issue I was referring to when I spoke with rock chip was the need
to pass the jack simple-card creates to the headset chip or codec.  We
need a way to specify a device like a tsa227e or rt5650 to pass the
jack to, which events are supported by the jack, and a generic API for
passing the jack.
Dylan Reid May 13, 2015, 11:11 p.m. UTC | #5
On Wed, May 13, 2015 at 10:21 AM, Dylan Reid <dgreid@chromium.org> wrote:
> On Wed, May 13, 2015 at 9:42 AM, Mark Brown <broonie@kernel.org> wrote:
>> On Wed, May 13, 2015 at 09:23:01PM +0800, zhengxing wrote:
>>> On 2015?05?13? 03:22, Mark Brown wrote:
>>
>>> >Is it not possible to extend simple card to handle your use cases?
>>> >Given the very generic naming and the fact that things like jack
>>> >detection and so on should depend on the CODEC and board usually rather
>>> >than on the SoC it doesn't sound like this is Rockchip specific.
>>
>>> >This also looks like you're reimplementing some device model enumeration
>>> >stuff which probably shouldn't be happening but let's understand the
>>> >problem you're trying to solve here before going too far into the code.
>>
>>> Because we are trying to bring rt5650 in the project, so we intend to
>>> describe supported codecs with DTS via only a rockchip machine driver file,
>>> others remain pre-implement(like max98090 / rt5645 that vendor machine
>>> driver).
>>
>> I don't undertand what you're saying here, sorry - why is this not just
>> a case of writing multiple machine drivers?
>
> I don't understand this either.  I'd think the best solution is
> simple-card, configured through DTS for each device.
>
>>
>>> I communicated with Dylan, and he told me that the jack detection is an
>>> issue in the simple-card, and suggested we are better to send them at
>>> present.
>>
>> But what are these issues?
>
> The issue I was referring to when I spoke with rock chip was the need
> to pass the jack simple-card creates to the headset chip or codec.  We
> need a way to specify a device like a tsa227e or rt5650 to pass the
> jack to, which events are supported by the jack, and a generic API for
> passing the jack.

I'm having some trouble envisioning how to pass the jack to the
headset chip in a generic way.  A callback could be added to
snd_soc_component_driver, or a snd_soc_headset_driver could be added.
The headset_drive would fit the ts3a227e well, but not the rt5645
which is also a full blown codec.
zhengxing May 14, 2015, 2:22 a.m. UTC | #6
On 2015?05?14? 07:11, Dylan Reid wrote:
> On Wed, May 13, 2015 at 10:21 AM, Dylan Reid<dgreid@chromium.org>  wrote:
>> On Wed, May 13, 2015 at 9:42 AM, Mark Brown<broonie@kernel.org>  wrote:
>>> On Wed, May 13, 2015 at 09:23:01PM +0800, zhengxing wrote:
>>>> On 2015?05?13? 03:22, Mark Brown wrote:
>>>>> Is it not possible to extend simple card to handle your use cases?
>>>>> Given the very generic naming and the fact that things like jack
>>>>> detection and so on should depend on the CODEC and board usually rather
>>>>> than on the SoC it doesn't sound like this is Rockchip specific.
>>>>> This also looks like you're reimplementing some device model enumeration
>>>>> stuff which probably shouldn't be happening but let's understand the
>>>>> problem you're trying to solve here before going too far into the code.
>>>> Because we are trying to bring rt5650 in the project, so we intend to
>>>> describe supported codecs with DTS via only a rockchip machine driver file,
>>>> others remain pre-implement(like max98090 / rt5645 that vendor machine
>>>> driver).
>>> I don't undertand what you're saying here, sorry - why is this not just
>>> a case of writing multiple machine drivers?
>> I don't understand this either.  I'd think the best solution is
>> simple-card, configured through DTS for each device.

Hi Mark, Dylan,
I tried to use simple-card and had some trouble that jack detection. So 
my idea is simply:
                                                   /-- rockchip_max98090 
(to configure max98090, and no need to via DTS)
    rockchip_machine_driver  |-- rockchip_rt5645 (to configure 
rt5650/rt5645, and no need to via DTS)
(supported codecs via DTS)   \-- rockchip_(maybe other codecs)

It is right that it is base on original rockchip_max98090, but the old 
rockchip_max98090 used DTS.

I tried to explain my ideas. Your kind suggestions will be highly 
appreciated.

Thanks.
Lars-Peter Clausen May 15, 2015, 8:40 p.m. UTC | #7
On 05/14/2015 01:11 AM, Dylan Reid wrote:
> On Wed, May 13, 2015 at 10:21 AM, Dylan Reid <dgreid@chromium.org> wrote:
>> On Wed, May 13, 2015 at 9:42 AM, Mark Brown <broonie@kernel.org> wrote:
>>> On Wed, May 13, 2015 at 09:23:01PM +0800, zhengxing wrote:
>>>> On 2015?05?13? 03:22, Mark Brown wrote:
>>>
>>>>> Is it not possible to extend simple card to handle your use cases?
>>>>> Given the very generic naming and the fact that things like jack
>>>>> detection and so on should depend on the CODEC and board usually rather
>>>>> than on the SoC it doesn't sound like this is Rockchip specific.
>>>
>>>>> This also looks like you're reimplementing some device model enumeration
>>>>> stuff which probably shouldn't be happening but let's understand the
>>>>> problem you're trying to solve here before going too far into the code.
>>>
>>>> Because we are trying to bring rt5650 in the project, so we intend to
>>>> describe supported codecs with DTS via only a rockchip machine driver file,
>>>> others remain pre-implement(like max98090 / rt5645 that vendor machine
>>>> driver).
>>>
>>> I don't undertand what you're saying here, sorry - why is this not just
>>> a case of writing multiple machine drivers?
>>
>> I don't understand this either.  I'd think the best solution is
>> simple-card, configured through DTS for each device.
>>
>>>
>>>> I communicated with Dylan, and he told me that the jack detection is an
>>>> issue in the simple-card, and suggested we are better to send them at
>>>> present.
>>>
>>> But what are these issues?
>>
>> The issue I was referring to when I spoke with rock chip was the need
>> to pass the jack simple-card creates to the headset chip or codec.  We
>> need a way to specify a device like a tsa227e or rt5650 to pass the
>> jack to, which events are supported by the jack, and a generic API for
>> passing the jack.
>
> I'm having some trouble envisioning how to pass the jack to the
> headset chip in a generic way.  A callback could be added to
> snd_soc_component_driver, or a snd_soc_headset_driver could be added.
> The headset_drive would fit the ts3a227e well, but not the rt5645
> which is also a full blown codec.

Yea, our current jack detection code is quite rudimentary when it comes to 
writing generic code.

I think the proper way to support this is come up with the concept of jack 
detection providers and consumers. A component can register a jack detection 
provider just like it can register a DAI. And then in the board driver you'd 
just link the jack detection logic to the jack using the usual approach, 
which is also used for DAIs (e.g. of node or device name). The core would 
then take care of calling a enable callback or whatever is required to setup 
the jack detection logic in the driver.

This would also nicely solve the issue with the GPIO jack detectors, where 
we currently can't really handle -EPROBE_DEFER. The GPIO would be requested 
by a jack detection provider which can request them before the card is 
registered rather than having to do the requesting in the card's init callback.

- Lars
Mark Brown May 19, 2015, 11:16 a.m. UTC | #8
On Fri, May 15, 2015 at 10:40:59PM +0200, Lars-Peter Clausen wrote:

> I think the proper way to support this is come up with the concept of jack
> detection providers and consumers. A component can register a jack detection
> provider just like it can register a DAI. And then in the board driver you'd
> just link the jack detection logic to the jack using the usual approach,
> which is also used for DAIs (e.g. of node or device name). The core would
> then take care of calling a enable callback or whatever is required to setup
> the jack detection logic in the driver.

Yes, nobody has really cared about it since we started pushing things
out of the card init into the device level.  We would also need to add a
way to force microphone biases on for devices where that's not a part of
the jack detection IP.

> This would also nicely solve the issue with the GPIO jack detectors, where
> we currently can't really handle -EPROBE_DEFER. The GPIO would be requested
> by a jack detection provider which can request them before the card is
> registered rather than having to do the requesting in the card's init
> callback.

Cards should be able to do their requesting in their probe function
prior to registering with the core even without anything else, though
that needs a bit or refactoring too.
Dylan Reid May 19, 2015, 4:37 p.m. UTC | #9
On Tue, May 19, 2015 at 4:16 AM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, May 15, 2015 at 10:40:59PM +0200, Lars-Peter Clausen wrote:
>
>> I think the proper way to support this is come up with the concept of jack
>> detection providers and consumers. A component can register a jack detection
>> provider just like it can register a DAI. And then in the board driver you'd
>> just link the jack detection logic to the jack using the usual approach,
>> which is also used for DAIs (e.g. of node or device name). The core would
>> then take care of calling a enable callback or whatever is required to setup
>> the jack detection logic in the driver.
>
> Yes, nobody has really cared about it since we started pushing things
> out of the card init into the device level.  We would also need to add a
> way to force microphone biases on for devices where that's not a part of
> the jack detection IP.
>

Can the jacks can each be an aux_dev?  The jack driver would create
the jack at probe time and register it with the card in aux_dev->init.
cht_bsw_max98090_ti.c is already doing something similar, although all
contained in the machine driver.

If the jack detection circuit is integrated with a full codec, then
the codec driver can also create the jack and register it with the
card.

Then simple-card can have an optional property to specify aux devs.  A
GPIO jack device could handle simple switch-based jack detection.
Mark Brown May 21, 2015, 11:10 a.m. UTC | #10
On Tue, May 19, 2015 at 09:37:58AM -0700, Dylan Reid wrote:

> Can the jacks can each be an aux_dev?  The jack driver would create
> the jack at probe time and register it with the card in aux_dev->init.
> cht_bsw_max98090_ti.c is already doing something similar, although all
> contained in the machine driver.

Yes, that's just a CODEC driver registered without any DAIs connected so
it'd just be another CODEC driver.

> Then simple-card can have an optional property to specify aux devs.  A
> GPIO jack device could handle simple switch-based jack detection.

That's useful anyway for external headphone/speaker drivers.

Patch
diff mbox

diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index e181826..e3f51cf 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -14,3 +14,10 @@  config SND_SOC_ROCKCHIP_I2S
 	  Say Y or M if you want to add support for I2S driver for
 	  Rockchip I2S device. The device supports upto maximum of
 	  8 channels each for play and record.
+
+config SND_SOC_ROCKCHIP_MACHINE
+	tristate "Rockchip Generic Machine Driver"
+	depends on CLKDEV_LOOKUP && SND_SOC_ROCKCHIP
+	help
+	  Say Y or M if you want to add support for Machine driver
+	  for Rockchip I2S device.
diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile
index b921909..47d7c84 100644
--- a/sound/soc/rockchip/Makefile
+++ b/sound/soc/rockchip/Makefile
@@ -2,3 +2,8 @@ 
 snd-soc-i2s-objs := rockchip_i2s.o
 
 obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-i2s.o
+
+# ROCKCHIP Machine Support
+snd-soc-rockchip-machine-objs := rockchip_machine_driver.o
+
+obj-$(CONFIG_SND_SOC_ROCKCHIP_MACHINE) += snd-soc-rockchip-machine.o
diff --git a/sound/soc/rockchip/rockchip_machine_driver.c b/sound/soc/rockchip/rockchip_machine_driver.c
new file mode 100644
index 0000000..34cae3f
--- /dev/null
+++ b/sound/soc/rockchip/rockchip_machine_driver.c
@@ -0,0 +1,210 @@ 
+/*
+ * Rockchip machine ASoC driver for boards for multi-codecs.
+ *
+ * Copyright (c) 2015, ROCKCHIP CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <linux/delay.h>
+#include <sound/core.h>
+#include <sound/jack.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#include "rockchip_i2s.h"
+#include "rockchip_machine_driver.h"
+
+#define DRV_NAME "rockchip-snd-machine"
+
+/* the sound cards of rockchp supports. */
+static struct rk_snd_soc_cards rk_snd_cards[] = {
+};
+
+static int snd_rk_mc_preinit(void)
+{
+	int id, ret;
+
+	for (id = 0; id < ARRAY_SIZE(rk_snd_cards); ++id) {
+		struct rk_snd_soc_cards *rk_snd_card = &rk_snd_cards[id];
+
+		ret = rk_snd_card->preinit(rk_snd_card);
+		if (ret < 0)
+			pr_warn("card: %s preinit failed!\n",
+				rk_snd_card->name);
+	}
+
+	return 0;
+}
+
+static int snd_rk_mc_probe(struct platform_device *pdev)
+{
+	struct rk_mc_private *drv;
+	struct snd_soc_card *card;
+	struct device_node *parent = pdev->dev.of_node;
+	struct device_node *node;
+	int found = 0;
+	int ret;
+
+	/* pre-init sound cards that rockchip supports. */
+	snd_rk_mc_preinit();
+
+	drv = devm_kzalloc(&pdev->dev, sizeof(*drv), GFP_KERNEL);
+	if (!drv)
+		return -ENOMEM;
+
+	/* attach matched codec. */
+	for_each_available_child_of_node(parent, node) {
+		int id;
+
+		for (id = 0; id < ARRAY_SIZE(rk_snd_cards); ++id) {
+			struct rk_snd_soc_cards *rk_snd_card =
+					&rk_snd_cards[id];
+
+			ret = of_device_is_compatible(node,
+						      rk_snd_card->compatible);
+			if (ret) {
+				/* match compatible. */
+				card = rk_snd_card->card;
+				if (!card || !card->dai_link) {
+					dev_err(&pdev->dev,
+						"card or dai_link is null!\n");
+					continue;
+				}
+
+				card->dev = &pdev->dev;
+				platform_set_drvdata(pdev, card);
+				snd_soc_card_set_drvdata(card, drv);
+
+				/* set dai link node. */
+				card->dai_link->codec_of_node =
+					of_parse_phandle(node,
+							 "rockchip,audio-codec",
+							 0);
+				if (!card->dai_link->codec_of_node) {
+					dev_err(&pdev->dev,
+						"rockchip,audio-codec invalid\n");
+					continue;
+				}
+
+				card->dai_link->cpu_of_node =
+					of_parse_phandle(node,
+							 "rockchip,i2s-controller",
+							 0);
+				if (!card->dai_link->cpu_of_node) {
+					dev_err(&pdev->dev,
+						"rockchip,i2s-controller invalid\n");
+					continue;
+				}
+
+				if (card->aux_dev) {
+					/* set aux_dev for max98090. */
+					card->aux_dev->codec_of_node =
+						of_parse_phandle(node,
+								 "rockchip,headset-codec",
+								 0);
+					if (!card->aux_dev->codec_of_node) {
+						dev_err(&pdev->dev,
+							"rockchip,headset-codec invalid\n");
+						continue;
+					}
+				}
+
+				card->dai_link->platform_of_node =
+					card->dai_link->cpu_of_node;
+
+				ret = snd_soc_of_parse_card_name(card,
+								 "rockchip,model");
+				if (ret)
+					continue;
+
+				/* register the soc card. */
+				ret = snd_soc_register_card(card);
+				if (!ret) {
+					/*
+					 * register sound card ok,
+					 * and found matched codec.
+					 */
+					dev_info(&pdev->dev,
+						 "card:[%s] register success!\n",
+						 card->name);
+
+					found = 1;
+					goto found_codec;
+				} else {
+					/* register sound card failed */
+					dev_err(&pdev->dev,
+						"card:[%s] register failed(%d)!\n",
+						card->name, ret);
+
+					card->dev = NULL;
+				}
+			}
+		}
+	}
+
+	if (!found) {
+		dev_err(&pdev->dev,
+			"Not found matched codec!\n");
+		return -ENODEV;
+	}
+
+found_codec:
+	dev_info(&pdev->dev,
+		 "Found matched codec: %s!\n",
+		 card->name);
+
+	return 0;
+}
+
+static int snd_rk_mc_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+	snd_soc_card_set_drvdata(card, NULL);
+	snd_soc_unregister_card(card);
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static const struct of_device_id rockchip_machine_of_match[] = {
+	{ .compatible = "rockchip,rockchip-audio-machine", },
+	{},
+};
+
+static struct platform_driver snd_rk_mc_driver = {
+	.probe = snd_rk_mc_probe,
+	.remove = snd_rk_mc_remove,
+	.driver = {
+		.name = DRV_NAME,
+		.owner = THIS_MODULE,
+		.pm = &snd_soc_pm_ops,
+		.of_match_table = rockchip_machine_of_match,
+	},
+};
+
+module_platform_driver(snd_rk_mc_driver);
+
+MODULE_AUTHOR("Xing Zheng <zhengxing@rock-chips.com>");
+MODULE_DESCRIPTION("Rockchip general machine ASoC driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" DRV_NAME);
+MODULE_DEVICE_TABLE(of, rockchip_machine_of_match);
diff --git a/sound/soc/rockchip/rockchip_machine_driver.h b/sound/soc/rockchip/rockchip_machine_driver.h
new file mode 100644
index 0000000..39a7a77
--- /dev/null
+++ b/sound/soc/rockchip/rockchip_machine_driver.h
@@ -0,0 +1,30 @@ 
+/*
+ * sound/soc/rockchip/rockchip_machine_driver.h
+ *
+ * ALSA SoC Audio Layer - Rockchip Machine driver
+ *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng <zhengxing@rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ROCKCHIP_MACHINE_DRIVER_H__
+#define __ROCKCHIP_MACHINE_DRIVER_H__
+
+struct rk_mc_private {
+	struct snd_soc_jack headphone_jack;
+	struct snd_soc_jack mic_jack;
+	struct snd_soc_jack btn_jack;
+};
+
+struct rk_snd_soc_cards {
+	char name[32];
+	char compatible[128];
+	struct snd_soc_card *card;
+	int (*preinit)(struct rk_snd_soc_cards *soc_card);
+};
+
+#endif /* __ROCKCHIP_MACHINE_DRIVER_H__ */