On Thu, 2019-01-24 at 19:25 +0000, Mark Brown wrote:

On Thu, Jan 24, 2019 at 04:58:41PM +0800, KaiChieh Chuang wrote:

quoted

The driver function for transferring/receiving
BT encoded data to/from BT hardware.

It's really nice to see someone submitting a driver for actual radio
hardware, this is great to see!  

The driver looks pretty good, I've got a few quite minor comments below
but the main one is that given that this doesn't have any DAIs or DAPM
it looks like it doesn't integrate with the rest of the sound card much
so perhaps it could just be a free standing ALSA driver?  If there's
inputs that let you link it to the rest of the sound card which will be
added later then that's obviously a good reason to keep it in ASoC (I'd
not be surprised if there were) but otherwise I'm not sure what
advantage ASoC brings you.

Our btcvsd radio chip is tightly bound with baseband SoC,
Currently, the mtk-btcvsd resides in mtk afe sound cards,
such as mt6797-mt6351 sound card.

"free standing ALSA driver" i'm not quite sure what you mean by this,
do you mean something like usb sound card (sound/usb/)?
Unlike normal BT SCO chip is transfer with PCM format,
we transfer encoded data directly. It's a MTK hardware-proprietary,
i'm not sure a standalone ALSA driver can do any good here.
Thats why I decided to put it under sound/soc/mediatek/.

There's quite a few of these dev_info() calls which look like they might
be a bit noisy and could perhaps be dev_dbg() instead.

I'll cut down the log in next patch

Some of these enums (all of them except the narrow/wide band one) should
be simple number controls ending with Switch as covered in
control-names.rst, this helps UIs display them better.

I'll update this in next patch

quoted

+	SND_SOC_BYTES_TLV("btcvsd_tx_timestamp",
+			  sizeof(struct mtk_btcvsd_snd_time_buffer_info),
+			  btcvsd_tx_timestamp_get, NULL),

There's an ALSA timestamping API - see commit 4eeaaeaea1ce (ALSA: core:
add hooks for audio timestamps) and related commits.  I don't know if
that applies here and might be a better fit or not?

We would like to keep the exact time stamp during copy (read/write).
and the remain data in kernel temp buffer. I think its a little different
to ALSA API. I would prefer keeping this for now?