| Message ID | 1431422797-31903-2-git-send-email-zhengxing@rock-chips.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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.
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?
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.
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.
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.
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
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.
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.
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.
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__ */