Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver

Hello,

One example is how all the drivers that use the generic dmaengine code
instantiate their DMA drivers, or how all the drivers for CODECs that
have both I2C and SPIi control interfaces instantiate - given that the
device specific code here seems to be mostly data tables that's probably
the closest thing.

Thank you. I'm checking the ALSA drivers of other companies, I found Qualcomm's
QTi LPASS driver is similar with my wanted.

quoted

Thanks, I'll try it. Is there Documentation in

sound/designes/compress-offload.rst?

quoted

And best sample is... Intel's driver?

Yes.

I read Intel's driver, I understand how to define the compress CPU DAI and
snd_compr_ops. The driver of Intel Atom (at sst-mfld-platform-pcm.c) defines
following DAI:
{
	.name = "compress-cpu-dai",
	.compress_new = snd_soc_new_compress,
	.ops = &sst_compr_dai_ops,
	.playback = {
		.stream_name = "Compress Playback",
		.channels_min = 1,
	},
},

But I can't find how to use/map this DAI in machine driver or Device-Tree or
something. I think that it's same as PCM DAI, am I correct?

I read compress-offload.rst, but I can't find how do I test it. It seems aplay
of
alsa-util doesn't know compress audio formats. Should I use PulseAudio or
Android HAL to test compress audio APIs?


Regards,
--
Katsuhiro Suzuki

-----Original Message-----
From: Mark Brown [mailto:broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
Sent: Wednesday, December 6, 2017 9:58 PM
To: Suzuki, Katsuhiro/鈴木 勝博 <redacted>
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org; Rob Herring <redacted>;
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Yamada, Masahiro/山田 真弘
[off-list ref]; Masami Hiramatsu
[off-list ref]; Jassi Brar [off-list ref];
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver

On Wed, Dec 06, 2017 at 03:03:18PM +0900, Katsuhiro Suzuki wrote:

quoted

quoted

I'd expect this code to be structured more like a library - have a
driver that handles the specific IPs then have it call into a shared
block of code that does the generic bits.  Though in this case the
device specific bit looks like a couple of tiny data tables so I'm not
sure it's worth making it conditional or separate at all.

quoted

Sorry... I agree your opinion, but I can't imagine the detail.

quoted

I think my driver has structure as follows (ex. startup):
  DAI: uniphier_aio_startup()@aio-core.c
  Lib: uniphier_aio_init()@aio-regctrl.c
  SoC specific: uniphier_aio_ld11_spec@aio-ld11.c

quoted

Am I wrong? Would you mean split the functions in aio-regctl.[ch] to other
kernel module? I wonder if you could tell me the example from existing
drivers. I'll try to fix my driver like as it.

One example is how all the drivers that use the generic dmaengine code
instantiate their DMA drivers, or how all the drivers for CODECs that
have both I2C and SPIi control interfaces instantiate - given that the
device specific code here seems to be mostly data tables that's probably
the closest thing.

quoted

quoted

At least.  I do think we need to get to the bottom of how flexible the
hardware is first though.

quoted

Yes, indeed. This hardware is more flexible and complex, but now I (and our
company) don't use it. Of course, I don't want to hide some features of this
hardware from ALSA people. I should try to upstream all features in the

future,

quoted

I think.

My main concern here is to make sure that when you decide you need to
use the more complex hardware that this can be done without too much
pain to existing machines (and that they can benefit from as much of the
enhanced functionality as is possible).

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html