| Message ID | 1493712508-27919-1-git-send-email-vishalthanki@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, May 02, 2017 at 10:08:28AM +0200, Vishal Thanki wrote: > Add device tree support for the dummy codec > driver. Why would this be useful? If the device is a dummy device for internal use obviously it doesn't actually exist which tends to suggest that it shouldn't be represented in the DT either as the DT should describe the hardware.
On Sun, May 14, 2017 at 11:56 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, May 02, 2017 at 10:08:28AM +0200, Vishal Thanki wrote: >> Add device tree support for the dummy codec >> driver. > > Why would this be useful? If the device is a dummy device for internal > use obviously it doesn't actually exist which tends to suggest that it > shouldn't be represented in the DT either as the DT should describe the > hardware. Thanks for you comments. Actually in our custom hardware, the codec is not accessible/visible from kernel directly, rather additional MCU controls and configures it. However MCU needs the I2S clocks and data from kernel. So I am using I2S platform driver from Linux just to configure I2S clocks, and registering a dummy codec driver to DAI link in DT, so that codec can be instantiated and clocks can be enabled from user-space ALSA utils while accessing this dummy codec. Please suggest if there is any better way to achieve this kind of configuration. Thanks, Vishal
On Mon, May 15, 2017 at 10:41:43AM +0200, Vishal Thanki wrote: > Thanks for you comments. Actually in our custom hardware, the codec is > not accessible/visible from kernel directly, rather additional MCU > controls and configures it. However MCU needs the I2S clocks and data > from kernel. So I am using I2S platform driver from Linux just to > configure I2S clocks, and registering a dummy codec driver to DAI link > in DT, so that codec can be instantiated and clocks can be enabled > from user-space ALSA utils while accessing this dummy codec. Please > suggest if there is any better way to achieve this kind of > configuration. You should be representing the I2S control offered by the MCU as a CODEC driver. Even if there's no changes ever made there must be some constraints.
diff --git a/sound/soc/soc-utils.c b/sound/soc/soc-utils.c index 644d9a9..c76b938 100644 --- a/sound/soc/soc-utils.c +++ b/sound/soc/soc-utils.c @@ -19,6 +19,8 @@ #include <sound/pcm.h> #include <sound/pcm_params.h> #include <sound/soc.h> +#include <linux/module.h> +#include <linux/of.h> int snd_soc_calc_frame_size(int sample_size, int channels, int tdm_slots) { @@ -359,9 +361,19 @@ static int snd_soc_dummy_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_OF +static const struct of_device_id dummy_dt_ids[] = { + { .compatible = "linux,snd-soc-dummy", }, + { } +}; +MODULE_DEVICE_TABLE(of, dummy_dt_ids); +#endif + + static struct platform_driver soc_dummy_driver = { .driver = { .name = "snd-soc-dummy", + .of_match_table = of_match_ptr(dummy_dt_ids), }, .probe = snd_soc_dummy_probe, .remove = snd_soc_dummy_remove,
Add device tree support for the dummy codec driver. Signed-off-by: Vishal Thanki <vishalthanki@gmail.com> --- sound/soc/soc-utils.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)