On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com> wrote:

Would it be possible for us to conduct discussion on the UEFI talkbox?
I don't mind using email, but things could definitely get moving
quicker over there (though its not a requirement obviously).

Here's how I generally envision the driver functioning:

1. Firmware/platform code calls InitaudioOutput() or something like
it. This function scans the PCIe bus and scans for one of the
following:
- Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
- PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
USB audio interface (I'm only thinking of targeting XHCI and USB 4,
and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
hands. If so, it will make things easier.
- For USB audio devices I'm not quite sure what to look for; I'm
definitely unused to USB.
2. If any of the above cases are found, appropriate driver
initialization occurs. Since for the time being I am solely focusing
on VirtIO sound devices, the VirtIO general initialization sequence
will occur as outlined in sec. 3 of the VirtIO specification available
at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html.
As for actual protocol exposure that would be spec-worthy, for
EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
is rather simple: there's a buffer for sending and receiving audio
data in PCM streams. So for that we could expose a Reset(),
RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
Prepare(), Release(), Start(), and Stop() function for the
corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
lot more complex, so I'm not sure how that should work.
For VirtIO -- which is what I'll focus on for now -- everything is
described, in excellent detail, in sec. 5.14 of the above-linked
document. What are your guys's thoughts thus far and how should
everything be mapped to UEFI interfaces?

On 4/13/21, Andrew Fish <afish@apple.com> wrote:

Leif,

Since I have put some brain cells around this area in the past I can be the
backup and help out too.

I’d also point out if you are having issues building or have general
questions on how things work it is fine to use the mailing list. I’ve got a
lot of feedback that folks read or search the mailing list looking for
answer to their questions so one person asking can help out a lot of other
people.

Thanks,

Andrew Fish

On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com> wrote:

Hi all, especially Ethin.

Apologies for radio silence - last week I was off on holiday, and before
that ... let's just say corporate acquisitions generate some
distractions.
Anyway, I'm back, and since I'm down as the mentor for this task, feel
free to spam me with any remaining/new questions.

/
   Leif

On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>> wrote:
I'll attach the bug for the build tools to the BZ shortly.
Laszlo, thanks for that. I don't know their email addresses though.
And yes, I was going to make it device independent, as the majority
(if not all) of UEFI protocols are.

On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>
wrote:

On 03/31/21 08:41, Nate DeSimone wrote:

Another option is to put the protocol definition in MdeModulePkg and
mark it with the EDKII_ prefix. For my last “code first” UEFI spec
contribution I did this with the PPI that added up getting added.

The new audio protocol should be generic, only its implementation in
question should be virtio specific.

Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
the developers of the virtio-sound device model in QEMU.

Thanks
Laszlo

Thanks,

Nate



*From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>> on behalf
of "Andrew Fish via groups.io <http://groups.io/>"
<afish=apple.com@groups.io <mailto:apple.com@groups.io>>
*Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>"
<devel@edk2.groups.io <mailto:devel@edk2.groups.io>>,
"afish@apple.com <mailto:afish@apple.com>" <afish@apple.com
<mailto:afish@apple.com>>
*Date: *Tuesday, March 30, 2021 at 10:54 PM
*To: *edk2-devel-groups-io <devel@edk2.groups.io
<mailto:devel@edk2.groups.io>>,
"harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>"
<harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
*Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>
*Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)





   On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>
   <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
wrote:



   I'm wondering where exactly I should add the VirtIO sound protocol.
I
   just familiarized myself with the build system and am about to
test
it
   by building OVMF if possible, but I'm wondering where I should
   actually put the protocol and all that stuff. Maybe there's
   documentation I've missed as well.



Ethin,



For the driver I’d match the patter of OVMF [1] and use
OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
template.



The protocol is more of a public thing. I think eventually we would
like
to publish the protocol in the UEFI Spec (I can help with that part)
and
that would mean we put the Protocol definition in
MdePkg/Include/Protocol, but we don’t want to do that before it is
standardized as that causes compatibility issues. So this is a “code
first project” (code prototype and then contribute to the UEFI Forum
for
inclusion in the specification) so we need to follow some code first
rules that I don’t remember of the top of my head? So why not start
out
the protocol definition OvmfPkg/Include/Protocol. You can also add a
test application looks like you can just use the root [2] of OVMF for
that. That way the project is not blocked.



We can have a conversation on the mailing list about better places to
put stuff, and it should be easy enough to move stuff around if
everything else is working.



[1] find OvmfPkg  -iname '*Virtio*.inf'

OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf

OvmfPkg/VirtioScsiDxe/VirtioScsi.inf

OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf

OvmfPkg/Library/VirtioLib/VirtioLib.inf

OvmfPkg/VirtioGpuDxe/VirtioGpu.inf

OvmfPkg/VirtioBlkDxe/VirtioBlk.inf

OvmfPkg/Virtio10Dxe/Virtio10.inf

OvmfPkg/VirtioNetDxe/VirtioNet.inf

OvmfPkg/VirtioRngDxe/VirtioRng.inf



[2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
grep MODULE_TYPE

EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
   = UEFI_APPLICATION



Thanks,



Andrew Fish






   On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
<http://groups.io/ <http://groups.io/>>
   <harlydavidsen=gmail.com@groups.io <mailto:gmail.com@groups.io>
   <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
<mailto:gmail.com@groups.io>>> wrote:

       I agree. Plus, it gives me a chance to finally learn the EDK2
build
       system and how it works! I've been working on a hobby OS as a
side
       project and, though learning from other code examples from
OSes
is
       fun, I have to say that learning from the firmware code like
from
       SeaBIOS has been some of the most enlightening and interesting
times
       thus far.
       Thanks for the link to your code, Rafael; once I get virtIO
support
       in, I can work on HDA support, though I might tackle USB
support
       second and HDA third. We'll see, but VirtIO definitely is
coming
       first.

       As I said before, I look forward to working with all of you
       wonderful
       people!

       On 3/30/21, Rafael Rodrigues Machado
       <rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
       <mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>>
       wrote:

           This would be amazing so people can continue my work
related
to
           accessibility at BIOS. Something desired by the blind
people
           since the
           90's
           Just for reference, this is what I have done:


https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>

           Thanks
           Rafael

           Em seg, 29 de mar de 2021 20:24, Ethin Probst
           <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
           escreveu:


               Hello everyone,

               This is the first time I've ever contributed to EDK2.
As
               part of GSoC
               2021, I have submitted a proposal to implement a UEFI
               audio output
               protocol that will utilize the VirtIO sound driver.
I've
               already
               submitted a draft proposal, and apologize if I've done
               things out of
               order. This is my first time doing GSoC 2021, and
               contributing to EDK2
               felt like a really fun thing to do!

               I look forward to working with you guys on this and
any
               future projects!
               :-)

               --
               Signed,
               Ethin D. Probst









       --
       Signed,
       Ethin D. Probst







   --
   Signed,
   Ethin D. Probst

--
Signed,
Ethin D. Probst

-- 
Signed,
Ethin D. Probst