<div dir="ltr"><div>Hi Mark</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 7, 2023 at 11:13 AM Shengjiu Wang <<a href="mailto:shengjiu.wang@gmail.com">shengjiu.wang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Mark</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 4, 2023 at 12:03 PM Shengjiu Wang <<a href="mailto:shengjiu.wang@gmail.com" target="_blank">shengjiu.wang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 4, 2023 at 1:59 AM Mark Brown <<a href="mailto:broonie@kernel.org" target="_blank">broonie@kernel.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jul 03, 2023 at 03:12:55PM +0200, Hans Verkuil wrote:<br>
<br>
> My main concern is that these cross-subsystem drivers are a pain to<br>
> maintain. So there have to be good reasons to do this.<br>
<br>
> Also it is kind of weird to have to use the V4L2 API in userspace to<br>
> deal with a specific audio conversion. Quite unexpected.<br>
<br>
> But in the end, that's a decision I can't make.<br>
<br>
> So I wait for that feedback. Note that if the decision is made that this<br>
> can use V4L2, then there is quite a lot more that needs to be done:<br>
> documentation, new compliance tests, etc. It's adding a new API, and that<br>
> comes with additional work...<br>
<br>
Absolutely, I agree with all of this - my impression was that the target<br>
here would be bypass of audio streams to/from a v4l2 device, without<br>
bouncing through an application layer.  If it's purely for audio usage<br>
with no other tie to v4l2 then involving v4l2 does just seem like<br>
complication.<br></blockquote><div><br></div><div>This audio use case is using the v4l2 application layer. in the user space</div><div>I need to call below v4l2 ioctls to implement the feature: </div><div>VIDIOC_QUERYCAP<br></div><div>VIDIOC_TRY_FMT<br></div><div>VIDIOC_S_FMT<br></div><div>VIDIOC_REQBUFS<br></div><div>VIDIOC_QUERYBUF<br></div><div>VIDIOC_STREAMON<br></div><div>VIDIOC_QBUF<br></div><div>VIDIOC_DQBUF<br></div><div>VIDIOC_STREAMOFF<br></div><div><br></div><div>why the driver was put in the ALSA, because previously we implemented</div><div>the ASRC M2P (memory to peripheral) in ALSA,  so I think it is better to</div><div>add M2M driver in ALSA.  The hardware IP is the same. The compatible</div><div>string is the same. </div><div><br></div><div><br></div></div></div></blockquote><div>Could you please share more of your ideas about this patch? and could</div><div>you please check further about this implementation.</div><div><br></div><div>I tried to find a good interface in ALSA for this m2m request, but didn't</div><div>find one,  then I try the V4L2, find it is good this audio case.</div><div><br></div><div>but it needs to extend the V4L2 API. </div><div><br></div><div>I have no idea how to go on, could you please recommend?  </div><div><br></div></div></div></blockquote><div><br></div><div>Should I implement the asrc m2m driver as a separate v4l2 driver?</div><div>And move it to the /driver/media folder ? In ALSA part, just need</div><div>register the platform device.</div><div><br></div><div>The bridge between ALSA and V4L2 framework can be the header</div><div>file in /include/sound/ </div><div><br></div><div>Does it sound better? <br></div><div><br></div><div>Best regards</div><div>Wang Shengjiu</div></div></div>