From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) by mx.groups.io with SMTP id smtpd.web08.84.1618444475852211575 for ; Wed, 14 Apr 2021 16:54:36 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=XgsjhFbp; spf=pass (domain: apple.com, ip: 17.171.2.72, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 13ENqxwI040209; Wed, 14 Apr 2021 16:54:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=MpXEXKRkZr7+2iJQvsM+HXNLBYh/q8g0hoPqEIavKyc=; b=XgsjhFbpbqIpkFw9Xu/neczLA/3CEcJcK5Hv+PjFSOjat/Q8YRlpct+46X4AOdsN2xND fnIXTpF/OHQq4NI0LWvZAkbD5W52B526ugo5Bs+8nrdoOwcDXr1QSBI5Jeipkm9bbq9i MyvKsj1fIfk6pEIHy+s9uRda9s1a7bwzqa6Ov1G3/+HwEnrTXywub48lYLQC4SInmb7S 7KD7t4rJz34Veo7ngzPuZ/g2MGPBV6JboH3QpfSlvUeqzltD8TjsFOVB8DY2HVrN2Soa Kt9UcHlwG2TJ2ph67zfGkcJ0XpZhuNkQcgGEY/4na1aSCzDhSRf1WemBYzUF4SveANhG Jw== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 37v1kpq58p-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 14 Apr 2021 16:54:34 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QRK00NPNVQVDW20@rn-mailsvcp-mta-lapp04.rno.apple.com>; Wed, 14 Apr 2021 16:54:31 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QRK00T00V84CC00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 14 Apr 2021 16:54:31 -0700 (PDT) X-Va-A: X-Va-T-CD: da3a4df698400084da27c6ab403bcb35 X-Va-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-Va-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-Va-CD: 0 X-Va-ID: 539f5eb7-8783-42d9-a6a3-fa8e1bdc6f8d X-V-A: X-V-T-CD: da3a4df698400084da27c6ab403bcb35 X-V-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-V-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-V-CD: 0 X-V-ID: 3d95ac2e-f97f-468e-b009-ed73e439313b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-14_15:2021-04-14,2021-04-14 signatures=0 Received: from [17.235.1.165] (unknown [17.235.1.165]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QRK00RMRVQTTY00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 14 Apr 2021 16:54:30 -0700 (PDT) From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) Date: Wed, 14 Apr 2021 16:54:29 -0700 In-reply-to: Cc: "devel@edk2.groups.io" , "harlydavidsen@gmail.com" , Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann To: Mike Kinney References: <16713E6D64EE917D.25648@groups.io> <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> <16758FB6436B1195.32393@groups.io> X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-14_15:2021-04-14,2021-04-14 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_607152E1-DE0D-4FFF-AD29-4D6000A2A009" --Apple-Mail=_607152E1-DE0D-4FFF-AD29-4D6000A2A009 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 14, 2021, at 3:30 PM, Kinney, Michael D wrote: >=20 > Hi Ethin, >=20 > Most UEFI Drivers do use polling. >=20 > If it is a blocking I/O operation the UEFI Driver waits for completion. = Typically by polling a status register until the I/O is complete and then = return status. >=20 > If it is a non-blocking I/O Operation, then the UEFI Driver can create a= timer event to periodically check the completion status. >=20 > Non-blocking APIs may also use an event to know when the I/O operation i= s completed and this can be used with the CheckEvent() service to poll for = event completion. >=20 > These concepts are discussed in the UEFI Driver Writer's Guide. >=20 > https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-= UefiDriverWritersGuide-draft.pdf >=20 > Specifically for audio. If there is an audio playback buffer that will = take some time to send, > the Audio Protocol would likely define a non-blocking interface to start= playback. You may need > an event that is signaled when more audio data is needed or when the pla= yback is complete. You > will need to think about the consumer of the Audio Protocol and how it w= ill interact with the=20 > Audio Protocol and if the consumer also needs to do other activities whi= le audio is playing or > if it is ok for the consumer to wait until the audio playback is complet= ed. >=20 Mike, It is likely we want async and synchronous playback. If you are playing a = boot bong you don=E2=80=99t want to block on its completion. If you are doi= ng a GUI UI you don=E2=80=99t want to block on playback and then do a bunch= of GUI math etc.=20 Ethin, I=E2=80=99d take a look at some example drivers like VirtioBlkDxe[1]. It a= lso looks like there is already a VirtioLib[2] to help with house keeping. = I did a quick skim and I don=E2=80=99t see a VirtIo device with an Event dr= iven API. It looks like VirtioNetDxe[3] does have the concept of a callbac= k to poll [4], so you might be able to leverage that concept into a timer e= vent to check for completion.=20 I=E2=80=99d not get hung up on the asynchronous part of the API. It might = make sense to implement the synchronous version of the API in the driver 1s= t and fake the async for your 1st pass.=20 If you look at other UEFI Async APIs they generally pass around a Token (u= sually an Event to signal on completion, and an EFI_STATUS)[5]. Thus faking= the Async means making it look like the event fired before your API return= ed. Assuming that *Token is an argument to the protocol you do this to fake= the Async transaction=E2=80=A6. If (Token !=3D NULL) { Token->TransactionStatus =3D Status; gBS->SignalEvent (Token->Event); } This just make it look to the caller like the transaction completed by the= time you returned to the caller. So from a caller perspective that is a va= lid way the API could work. The other upside to this is you can make a UEFI= Shell App to test the protocol and also add a path to test the async API, = even if for the 1st pass implementation that is faked out.=20 [1] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioBlkDxe [2] https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/VirtioLi= b/VirtioLib.c [3] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioNetDxe [4] https://github.com/tianocore/edk2/blob/master/OvmfPkg/VirtioNetDxe/Eve= nts.c#L32 [5] https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/= BlockIo2.h#L41 Thanks, Andrew Fish > Mike >=20 >> -----Original Message----- >> From: devel@edk2.groups.io > On Behalf Of Ethin Probst >> Sent: Wednesday, April 14, 2021 1:48 PM >> To: Andrew Fish > >> Cc: edk2-devel-groups-io >; Leif Lindholm >; Laszl= o Ersek >; >> Desimone, Nathaniel L >; Rafael Rodrigues Machado >; Gerd >> Hoffmann > >> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) >>=20 >> These are some pretty good suggestions; however, while reading through >> the VirtIO specification again yesterday, I (re)-discovered that >> VirtIO devices are usually interrupt based. In particular, a VirtIO >> PCI/PCIe device defines the common, notifications, ISR status, >> device-specific configuration, PCI configuration access, shared memory >> region, and vendor-specific data capability structures in PCI >> configuration space. It doesn't look like the EFI_CREATE_EVENT or >> EFI_CREATE_EVENT_EX function works via interrupts, from what I can >> tell. I'm not sure but it doesn't seem like there's a way I can poll >> the device, though I might be missing something. >> The idea for the generic protocol is good. The interrupt issue might >> be a problem though and I'm not sure how to actually solve that. >>=20 >> On 4/13/21, Andrew Fish wrote: >>> Ethin, >>>=20 >>> In terms of defining the protocol stack it is good to start with the >>> producers and consumers and think about the problem from both perspect= ives. >>> It is easy enough to think about the producer part of it as you are th= inking >>> about writing the driver. The driver is going to consume things like t= he PCI >>> I/O Protocol. >>>=20 >>> The consumer of the sound Protocol is going to most likely be generic = EFI >>> platform code, and possibly an OS loader. In the boot process Audio ha= s >>> traditionally be used for error codes, sign of life (for example the f= amous >>> Mac startup sound). We are also would like to have the option of enabl= ing >>> better accessibility features, especially for people how are visually >>> impaired. These days a lot of software engineers think of disk space a= s free >>> and really don=E2=80=99t consider the size of software, but this is no= t true for >>> firmware. Firmware generally lives in NOR FLASH that is considered exp= ensive >>> (it is more expensive than NAND, but at the same time more reliable) s= o >>> firmware implementations are constrained by the size of the code that = can be >>> carried, and the size of assets/resources that can be used for user >>> interfaces. The OS loader is some what less constrained, but it still = has to >>> share the EFI System Partition on the disk with potentially other OS >>> loaders. >>>=20 >>> So the consumer wants a protocol that is unleveled and focused on the = task >>> at hand. I=E2=80=99m not too caught up on the names but in general I t= hink things >>> you want are (How many knobs we need is probably better answered by an >>> audiophile, and that is not me): >>> 1) CompatibleBuffer() - Does driver support this buffer format. >>> 2) PlayBuffer() - Play the sound >>> =09a) We probably want a synchronous and asynchronous version of this = API. For >>> example you don=E2=80=99t want to slow down the boot to wait for a boo= t beep to >>> complete, and you may chose to implement an API that waits for the sou= nd to >>> complete (and do some GUI work in parallel) vs. blocking on the sound. >>> =09b) async in EFI usually means you return a pointer to an EFI_EVENT = that >>> gets signaled on completion. >>> 3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be st= opped. >>> Think error exit. >>> 3) SetVolume()/GetVolume() - Set/Get Volume in units of 0 - 100 (tryin= g to >>> avoid db as that gets into capability and math that is likely best >>> abstracted by the driver)? >>> 4) Mute()/UnMute() - Mute and volume are often independent features in= a UI >>> keeping them separate in API makes it easier to implement things. >>> 5) PlayTone() - Maybe for error sounds that don=E2=80=99t require cann= ed sound >>> files. Maybe TimeOn, TimeOff, Frequency, and how many times to repeat. >>> 6) Do we need tuning values or Tone settings? >>>=20 >>> At some point we might consider defining nvram variable for the defaul= t >>> state of some of the tunable, especially mute and volume. For example = the >>> user may want to turn off all volume on the system so it would be nice= if >>> the OS can set the EFI volume and mute. In the short run we can probab= ly use >>> PCD values to set the default values. >>>=20 >>> So I think we have a generic AUDIO API on top and likely a PCI I/O on = the >>> bottom. If we need more protocols to manage hardware devices then thos= e >>> protocols can be defined in the context of that hardware. So for examp= le we >>> would probably end up with an HDA_CODEC protocol. I think the best way= to >>> think about this is a disk. A lot of disk adapters just produce a raw = Block >>> I/O protocol, but for a more common bus like ATA or SCSI you might ha= ve an >>> extra driver in place to make the common bits common code. I think som= e of >>> the same layers may be in place here. So likely VirtIo is simple and j= ust >>> produces the generic AUDIO API, while an HDA audio driver also has to >>> abstract some of the complexity of its hardware implementation and sta= ndard. >>>=20 >>>=20 >>> In terms of picking the set of APIs and tunables it is probably good t= o >>> start with VirtIo and USB and see what set make sense and what you cou= ld and >>> could not implement. HDA Audio is so complex you might want to look at= it in >>> terms of the minute you have to implement to make it function. Think w= hat >>> assumptions are you forced to make to implement. >>>=20 >>> This is a vey 10,000 foot view to start with. I think you will need to= mix >>> this in the the reality of how it works in the real world to figure ou= t the >>> right abstraction, but then again that is the beauty of having an >>> implementation. Likely also get some feedback from audiophiles. >>>=20 >>> Oh and make sure you don=E2=80=99t go off an implement a lot of code j= ust because we >>> chose the wrong complexity or abstraction point. This is the one time = we get >>> to change the public APIs so lets feel free to adjust them to make the= most >>> sense for the job at hand. >>>=20 >>> Thanks, >>>=20 >>> Andrew Fish >>>=20 >>>> On Apr 13, 2021, at 6:20 PM, Ethin Probst >>>> wrote: >>>>=20 >>>> Okay, so looking at the EDK2 driver developers guide, here are my >>>> thoughts: >>>>=20 >>>> - Each audio driver will be a bus driver, even if it doesn't control >>>> buses in the traditional sense. >>>> - I think the initialization sequence should be different: there >>>> should be an AudioDxe, but it should contain three separate bus >>>> drivers for each kind of audio device supported. >>>> - For the VirtIO audio device driver, it'll most likely consume the >>>> PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL and >>>> EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an >>>> ordinary UEFI device driver. >>>> - The HDA audio device driver will consume the PCI I/O protocol and >>>> will produce different device handles per HDA controller found. I'd >>>> produce a handle per codec, but that seems overkill. Each handle will >>>> be attached to both an audio stream protocol and a controller >>>> management protocol. The audio stream protocol will manage the >>>> creation, control, and deletion of audio streams as well as the >>>> processing of audio data. The controller management protocol is >>>> responsible for allowing applications or other drivers to manage the >>>> HDA controller itself. >>>>=20 >>>> I haven't planned for the USB audio device driver yet, but these are >>>> my thoughts so far. What do you guys think? Am I over-complicating >>>> this setup? How can it be improved upon? >>>>=20 >>>> On 4/13/21, Ethin Probst via groups.io >>>> >>> > wrote: >>>>> Hi Andrew, >>>>>=20 >>>>> The developer guide for EDK2 drivers is a godsend. Thank you very >>>>> much, and thank you, Mike, for your excellent work on the guide! I m= ay >>>>> just ahve to do my building on Linux and not Windows -- unless the B= ug >>>>> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, at >>>>> any rate, since Windows hosts do not support VirtIO emulation and I >>>>> can't seem to find any way of emulating them in a guest machine with >>>>> Windows as a host. >>>>>=20 >>>>> On 4/13/21, Andrew Fish > >>>>> wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst >>>>>>> wrote: >>>>>>>=20 >>>>>>> Would it be possible for us to conduct discussion on the UEFI talk= box? >>>>>>> I don't mind using email, but things could definitely get moving >>>>>>> quicker over there (though its not a requirement obviously). >>>>>>>=20 >>>>>>=20 >>>>>> Sure, don=E2=80=99t think I=E2=80=99ve really used that but as long= as I get pointed >>>>>> int >>>>>> he >>>>>> right direction I can make it work. >>>>>>=20 >>>>>> For a device driver the general UEFI model is for the Entry point o= f >>>>>> the >>>>>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported() >>>>>> function >>>>>> matches on the PCI devices. The Start() function installs the Proto= cols >>>>>> to >>>>>> do work, and the Stop() undoes the Start(). >>>>>>=20 >>>>>> Mike Kinney started this back in the day and it describes how to wr= ite >>>>>> UEFI >>>>>> drivers: >>>>>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-W= riter%27s-Guide >>>>>>=20 >>>>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pro= tocol/DriverBinding.h#L157 >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Andrew Fish >>>>>>=20 >>>>>>> Here's how I generally envision the driver functioning: >>>>>>>=20 >>>>>>> 1. Firmware/platform code calls InitaudioOutput() or something lik= e >>>>>>> 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: f= or >>>>>>> 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 focusi= ng >>>>>>> on VirtIO sound devices, the VirtIO general initialization sequenc= e >>>>>>> will occur as outlined in sec. 3 of the VirtIO specification avail= able >>>>>>> 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. Virt= IO >>>>>>> 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 ar= e 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? >>>>>>>=20 >>>>>>> On 4/13/21, Andrew Fish >>>>>>> >> >>>>>>> wrote: >>>>>>>> Leif, >>>>>>>>=20 >>>>>>>> Since I have put some brain cells around this area in the past I = can >>>>>>>> be >>>>>>>> the >>>>>>>> backup and help out too. >>>>>>>>=20 >>>>>>>> I=E2=80=99d also point out if you are having issues building or h= ave general >>>>>>>> questions on how things work it is fine to use the mailing list. = I=E2=80=99ve >>>>>>>> got >>>>>>>> a >>>>>>>> lot of feedback that folks read or search the mailing list lookin= g >>>>>>>> for >>>>>>>> answer to their questions so one person asking can help out a lot= of >>>>>>>> other >>>>>>>> people. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> Andrew Fish >>>>>>>>=20 >>>>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> Hi all, especially Ethin. >>>>>>>>>=20 >>>>>>>>> Apologies for radio silence - last week I was off on holiday, an= d >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> / >>>>>>>>> Leif >>>>>>>>>=20 >>>>>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst >>>>>>>> >>>>>>>>> >>>>>>>>> = >>> >>>>>>>>> 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 thou= gh. >>>>>>>>> And yes, I was going to make it device independent, as the major= ity >>>>>>>>> (if not all) of UEFI protocols are. >>>>>>>>>=20 >>>>>>>>> On 4/6/21, Laszlo Ersek >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> wrote: >>>>>>>>>> On 03/31/21 08:41, Nate DeSimone wrote: >>>>>>>>>>> Another option is to put the protocol definition in MdeModuleP= kg >>>>>>>>>>> and >>>>>>>>>>> mark it with the EDKII_ prefix. For my last =E2=80=9Ccode firs= t=E2=80=9D UEFI spec >>>>>>>>>>> contribution I did this with the PPI that added up getting add= ed. >>>>>>>>>>=20 >>>>>>>>>> The new audio protocol should be generic, only its implementati= on >>>>>>>>>> in >>>>>>>>>> question should be virtio specific. >>>>>>>>>>=20 >>>>>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as = well >>>>>>>>>> as >>>>>>>>>> the developers of the virtio-sound device model in QEMU. >>>>>>>>>>=20 >>>>>>>>>> Thanks >>>>>>>>>> Laszlo >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>>=20 >>>>>>>>>>> Nate >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> *From: * >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>> = on >>>>>>>>>>> behalf >>>>>>>>>>> of "Andrew Fish via groups.io >>>>>>>>>>> > >>>>>>>>>> >>>>>>>>>>> >>" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>>> *Reply-To: *"devel@edk2.groups.io >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>" >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>, >>>>>>>>>>> "afish@apple.com >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>>> >>" >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM >>>>>>>>>>> *To: *edk2-devel-groups-io >>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>, >>>>>>>>>>> "harlydavidsen@gmail.com >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>" >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>>> *Cc: *Rafael Rodrigues Machado >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Mar 30, 2021, at 5:01 PM, Ethin Probst >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I'm wondering where exactly I should add the VirtIO sound >>>>>>>>>>> protocol. >>>>>>>>>>> I >>>>>>>>>>> just familiarized myself with the build system and am about t= o >>>>>>>>>>> test >>>>>>>>>>> it >>>>>>>>>>> by building OVMF if possible, but I'm wondering where I shoul= d >>>>>>>>>>> actually put the protocol and all that stuff. Maybe there's >>>>>>>>>>> documentation I've missed as well. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Ethin, >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> For the driver I=E2=80=99d match the patter of OVMF [1] and us= e >>>>>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drive= rs >>>>>>>>>>> as >>>>>>>>>>> a >>>>>>>>>>> template. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> 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=E2=80=99t want to do that = before it is >>>>>>>>>>> standardized as that causes compatibility issues. So this is a >>>>>>>>>>> =E2=80=9Ccode >>>>>>>>>>> first project=E2=80=9D (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=E2=80=99t 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 O= VMF >>>>>>>>>>> for >>>>>>>>>>> that. That way the project is not blocked. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> We can have a conversation on the mailing list about better pl= aces >>>>>>>>>>> to >>>>>>>>>>> put stuff, and it should be easy enough to move stuff around i= f >>>>>>>>>>> everything else is working. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> [1] find OvmfPkg -iname '*Virtio*.inf' >>>>>>>>>>>=20 >>>>>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf >>>>>>>>>>>=20 >>>>>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf >>>>>>>>>>>=20 >>>>>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf >>>>>>>>>>>=20 >>>>>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf >>>>>>>>>>>=20 >>>>>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf >>>>>>>>>>>=20 >>>>>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf >>>>>>>>>>>=20 >>>>>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf >>>>>>>>>>>=20 >>>>>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf >>>>>>>>>>>=20 >>>>>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- >>>>>>>>>>> *.inf >>>>>>>>>>> | >>>>>>>>>>> grep MODULE_TYPE >>>>>>>>>>>=20 >>>>>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13: MODULE_TYPE >>>>>>>>>>> =3D UEFI_APPLICATION >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Andrew Fish >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 3/30/21, Ethin Probst via groups.io >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> >>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >> >>>>>>>>>>> =3Dgmail.com@grou= ps.io >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> 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 fro= m >>>>>>>>>>> OSes >>>>>>>>>>> is >>>>>>>>>>> fun, I have to say that learning from the firmware code l= ike >>>>>>>>>>> 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 virt= IO >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> As I said before, I look forward to working with all of y= ou >>>>>>>>>>> wonderful >>>>>>>>>>> people! >>>>>>>>>>>=20 >>>>>>>>>>> On 3/30/21, Rafael Rodrigues Machado >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> 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: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibil= ity >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >> >>>>>>>>>>>=20 >>>>>>>>>>> Thanks >>>>>>>>>>> Rafael >>>>>>>>>>>=20 >>>>>>>>>>> Em seg, 29 de mar de 2021 20:24, Ethin Probst >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>>> escreveu: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Hello everyone, >>>>>>>>>>>=20 >>>>>>>>>>> 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 drive= r. >>>>>>>>>>> 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! >>>>>>>>>>>=20 >>>>>>>>>>> I look forward to working with you guys on this a= nd >>>>>>>>>>> any >>>>>>>>>>> future projects! >>>>>>>>>>> :-) >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Signed, >>>>>>>>>>> Ethin D. Probst >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Signed, >>>>>>>>>>> Ethin D. Probst >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Signed, >>>>>>>>>>> Ethin D. Probst >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Signed, >>>>>>>>> Ethin D. Probst >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Signed, >>>>>>> Ethin D. Probst >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Signed, >>>>> Ethin D. Probst >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Signed, >>>> Ethin D. Probst >>>=20 >>>=20 >>=20 >>=20 >> -- >> Signed, >> Ethin D. Probst >>=20 >>=20 >>=20 --Apple-Mail=_607152E1-DE0D-4FFF-AD29-4D6000A2A009 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 14, 2= 021, at 3:30 PM, Kinney, Michael D <michael.d.kinney@intel.com> wrote:

Hi Ethin,

Most UEFI Drivers do use polling.=

If it is a blocking I/O operation the UEFI Driver waits fo= r completion.  Typically by polling a status register until the I/O is= complete and then return status.

If it is a non-blockin= g I/O Operation, then the UEFI Driver can create a timer event to periodica= lly check the completion status.  

Non-blocking APIs m= ay also use an event to know when the I/O operation is completed and this c= an be used with the CheckEvent() service to poll for event completion.

These concepts are discussed in the UEFI Driver Writer's Guid= e.

https://tianocore-docs.github.io/edk2-UefiDriverWr= itersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf

Specifi= cally for audio.  If there is an audio playback buffer that will take = some time to send,
the= Audio Protocol would likely define a non-blocking interface to start playb= ack.  You may need
an event that is signaled when more audio data is needed or when the playb= ack is complete.  You
will need to think about the consumer of the Audio Protocol and how = it will interact with the 
Audio Protocol and if= the consumer also needs to do other activities while audio is playing or
if it is ok for the cons= umer to wait until the audio playback is completed.


Mike,

It is likely we want async and synchronous playback. If you are playing = a boot bong you don=E2=80=99t want to block on its completion. If you are d= oing a GUI UI you don=E2=80=99t want to block on playback and then do a bun= ch of GUI math etc. 

Ethin,
<= div>
I=E2=80=99d take a look at some example drive= rs like VirtioBlkDxe[1]. It also looks like there is already a VirtioLib[2]= to help with house keeping. I did a quick skim and I don=E2=80=99t see a V= irtIo device with an Event driven API.  It looks like VirtioNetDxe[3] = does have the concept of a callback to poll [4], so you might be able to le= verage that concept into a timer event to check for completion. 
=

I=E2=80=99d not get hung up on the asynchron= ous part of the API. It might make sense to implement the synchronous versi= on of the API in the driver 1st and fake the async for your 1st pass. =

If you look at other UEFI Async APIs t= hey generally pass around a Token (usually an Event to signal on completion= , and an EFI_STATUS)[5]. Thus faking the Async means making it look like th= e event fired before your API returned. Assuming that *Token is an argument= to the protocol you do this to fake the Async transaction=E2=80=A6.
<= div>
If (Token !=3D NULL) {
  Token= ->TransactionStatus =3D Status;
  gBS->SignalEven= t (Token->Event);
}

This j= ust make it look to the caller like the transaction completed by the time y= ou returned to the caller. So from a caller perspective that is a valid way= the API could work. The other upside to this is you can make a UEFI Shell = App to test the protocol and also add a path to test the async API, even if= for the 1st pass implementation that is faked out. 


Thanks,

Andrew Fish

Mike

-----Original Message-----
From: devel@edk2.groups.io&nbs= p;<devel@edk2.= groups.io> On Behalf Of Ethin Probst
Sent: Wednesday, = April 14, 2021 1:48 PM
To: Andrew Fish <afish@apple.com>
Cc: edk2-= devel-groups-io <deve= l@edk2.groups.io>; Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek <lersek@redhat.com>;
= Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Rafael Rodrigues Machad= o <rafae= lrodrigues.machado@gmail.com>; Gerd
Hoffmann <kraxel@redhat.com>
Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

These are some pretty good suggestions; however, whil= e reading through
the VirtIO specification again yesterday, I= (re)-discovered that
VirtIO devices are usually interrupt ba= sed. In particular, a VirtIO
PCI/PCIe device defines the comm= on, notifications, ISR status,
device-specific configuration,= PCI configuration access, shared memory
region, and vendor-s= pecific data capability structures in PCI
configuration space= . It doesn't look like the EFI_CREATE_EVENT or
EFI_CREATE_EVE= NT_EX function works via interrupts, from what I can
tell. I'= m not sure but it doesn't seem like there's a way I can poll
= the device, though I might be missing something.
The idea for= the generic protocol is good. The interrupt issue might
be a= problem though and I'm not sure how to actually solve that.
=
On 4/13/21, Andrew Fish <afish@apple.com> wrote:
Ethin,

In terms of defin= ing the protocol stack it is good to start with the
producers= and consumers and think about the problem from both perspectives.
It is easy enough to think about the producer part of it as you are = thinking
about writing the driver. The driver is going to con= sume things like the PCI
I/O Protocol.

The consumer of the sound Protocol is going to most likely be generi= c EFI
platform code, and possibly an OS loader. In the boot p= rocess Audio has
traditionally be used for error codes, sign = of life (for example the famous
Mac startup sound). We are al= so would like to have the option of enabling
better accessibi= lity features, especially for people how are visually
impaire= d. These days a lot of software engineers think of disk space as free
and really don=E2=80=99t consider the size of software, but this i= s not true for
firmware. Firmware generally lives in NOR FLAS= H that is considered expensive
(it is more expensive than NAN= D, but at the same time more reliable) so
firmware implementa= tions are constrained by the size of the code that can be
car= ried, and the size of assets/resources that can be used for user
interfaces. The OS loader is some what less constrained, but it stil= l has to
share the EFI System Partition on the disk with pote= ntially other OS
loaders.

So the= consumer wants a protocol that is unleveled and focused on the task
at hand. I=E2=80=99m not too caught up on the names but in general = I think things
you want are (How many knobs we need is probab= ly better answered by an
audiophile, and that is not me):
1) CompatibleBuffer() - Does driver support this buffer format.<= br class=3D"">2) PlayBuffer() - Play the sound
a) We probably want a = synchronous and asynchronous version of this API. For
example= you don=E2=80=99t want to slow down the boot to wait for a boot beep tocomplete, and you may chose to implement an API that waits for = the sound to
complete (and do some GUI work in parallel) vs. = blocking on the sound.
b) async in EFI usually means you return a = pointer to an EFI_EVENT that
gets signaled on completion.
3) StopBuffer() - In case the asynchronous PlayBuffer() needs to= be stopped.
Think error exit.
3) SetVolume()/G= etVolume() - Set/Get Volume in units of 0 - 100 (trying to
av= oid db as that gets into capability and math that is likely best
abstracted by the driver)?
4) Mute()/UnMute() - Mute a= nd volume are often independent features in a UI
keeping them= separate in API makes it easier to implement things.
5) Play= Tone() - Maybe for error sounds that don=E2=80=99t require canned sound
files. Maybe TimeOn, TimeOff, Frequency, and how many times to r= epeat.
6) Do we need tuning values or Tone settings?

At some point we might consider defining nvram variab= le for the default
state of some of the tunable, especially m= ute and volume. For example the
user may want to turn off all= volume on the system so it would be nice if
the OS can set t= he EFI volume and mute. In the short run we can probably use
= PCD values to set the default values.

So I thi= nk we have a generic AUDIO API on top and likely a PCI I/O on the
bottom. If we need more protocols to manage hardware devices then th= ose
protocols can be defined in the context of that hardware.= So for example we
would probably end up with an HDA_CODEC pr= otocol. I think the best way to
think about this is a disk. A= lot of disk adapters just produce a raw Block
I/O  prot= ocol, but for a more common bus like ATA or SCSI you might have an
extra driver in place to make the common bits common code. I think s= ome of
the same layers may be in place here. So likely VirtIo= is simple and just
produces the generic AUDIO API, while an = HDA audio driver also has to
abstract some of the complexity = of its hardware implementation and standard.

<= br class=3D"">In terms of picking the set of APIs and tunables it is probab= ly good to
start with VirtIo and USB and see what set make se= nse and what you could and
could not implement. HDA Audio is = so complex you might want to look at it in
terms of the minut= e you have to implement to make it function. Think what
assum= ptions are you forced to make to implement.

Th= is is a vey 10,000 foot view to start with. I think you will need to mixthis in the the reality of how it works in the real world to fi= gure out the
right abstraction, but then again that is the be= auty of having an
implementation. Likely also get some feedba= ck from audiophiles.

Oh and make sure you don= =E2=80=99t go off an implement a lot of code just because we
chose the wrong complexity or abstraction point. This is the one time we g= et
to change the public APIs so lets feel free to adjust them= to make the most
sense for the job at hand.
Thanks,

Andrew Fish

On Apr 13, 2021, at 6:= 20 PM, Ethin Probst <harlydavidsen@gmail.com>
wrote:

Okay, so looking at the EDK2 driver developers guide, here are my=
thoughts:

- Each audio driver w= ill be a bus driver, even if it doesn't control
buses in the = traditional sense.
- I think the initialization sequence shou= ld be different: there
should be an AudioDxe, but it should c= ontain three separate bus
drivers for each kind of audio devi= ce supported.
- For the VirtIO audio device driver, it'll mos= t likely consume the
PCI I/O protocol and produce the EFI_VIR= TIO_AUDIO_OUTPUT_PROTOCOL and
EFI_VIRTIO_AUDIO_INPUT_PROTOCOL= protocols. This will just be an
ordinary UEFI device driver.=
- The HDA audio device driver will consume the PCI I/O proto= col and
will produce different device handles per HDA control= ler found. I'd
produce a handle per codec, but that seems ove= rkill. Each handle will
be attached to both an audio stream p= rotocol and a controller
management protocol. The audio strea= m protocol will manage the
creation, control, and deletion of= audio streams as well as the
processing of audio data. The c= ontroller management protocol is
responsible for allowing app= lications or other drivers to manage the
HDA controller itsel= f.

I haven't planned for the USB audio device = driver yet, but these are
my thoughts so far. What do you guy= s think? Am I over-complicating
this setup? How can it be imp= roved upon?

On 4/13/21, Ethin Probst via groups.io <http://groups.io/>
<harlydavidsen=3Dgmail= .com@groups.io
<mailto:harlydavidsen=3Dgmail.com@groups.io&= gt;> wrote:
Hi Andrew= ,

The developer guide for EDK2 drivers is a go= dsend. Thank you very
much, and thank you, Mike, for your exc= ellent work on the guide! I may
just ahve to do my building o= n Linux and not Windows -- unless the Bug
-- bug 3302 -- has = been fixed. I'll have to do testing on Linux, at
any rate, si= nce Windows hosts do not support VirtIO emulation and I
can't= seem to find any way of emulating them in a guest machine with
Windows as a host.

On 4/13/21, Andrew Fish = <afish@apple.com <<= a href=3D"mailto:afish@apple.com" class=3D"">mailto:afish@apple.com>= >
wrote:


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 co= uld definitely get moving
quicker over there (though its not = a requirement obviously).


Sure, don=E2=80=99t think I=E2=80=99ve really used that but as long= as I get pointed
int
he
right di= rection I can make it work.

For a device drive= r the general UEFI model is for the Entry point of
the
driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported()=
function
matches on the PCI devices. The Start= () function installs the Protocols
to
do work, = and the Stop() undoes the Start().

Mike Kinney= started this back in the day and it describes how to write
U= EFI
drivers:
htt= ps://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-G= uide

[1]https://github.com/tianocore/edk2/= blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157

Thanks,

Andrew Fish
<= br class=3D"">
Here's how I generally e= nvision the driver functioning:

1. Firmware/pl= atform code calls InitaudioOutput() or something like
it. Thi= s function scans the PCIe bus and scans for one of the
follow= ing:
- Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound devic= e
- 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 ea= sier.
- For USB audio devices I'm not quite sure what to look= for; I'm
definitely unused to USB.
2. If any o= f the above cases are found, appropriate driver
initializatio= n occurs. Since for the time being I am solely focusing
on Vi= rtIO sound devices, the VirtIO general initialization sequence
will occur as outlined in sec. 3 of the VirtIO specification availableat https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html=
<https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.= html
<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 buffe= r 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 V= IRTIO_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_ST= ART, 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 no= w -- everything is
described, in excellent detail, in sec. 5.= 14 of the above-linked
document. What are your guys's thought= s thus far and how should
everything be mapped to UEFI interf= aces?

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

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

I=E2=80=99d also point out if you are having issues b= uilding or have general
questions on how things work it is fi= ne to use the mailing list. I=E2=80=99ve
got
a<= br class=3D"">lot of feedback that folks read or search the mailing list lo= oking
for
answer to their questions so one pers= on asking can help out a lot of
other
people.
Thanks,

Andrew Fis= h

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

Hi al= l, especially Ethin.

Apologies for radio silen= ce - 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 me= ntor for this task,
feel
free to spam me with a= ny remaining/new questions.

/
&n= bsp;Leif

On Tue, Apr 6, 2021 at 4:17 PM Ethin = Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@g= mail.com>
<mailto:harlydavidsen@gmail.com <mailto:ha= rlydavidsen@gmail.com>
<mailto: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:lerse= k@redhat.com>
<mailto:lersek@redhat.com <mailto:lers= ek@redhat.com>>
<mailto:lersek@redhat.com <mailto= :lersek@redhat.com>
<mailto:lersek@redhat.com <mailt= o:lersek@redhat.com>>>>
wrote:
On 03/31/21 08:41, Nate DeSimone wrote:
Another option is to put t= he protocol definition in MdeModulePkg
and
mark= it with the EDKII_ prefix. For my last =E2=80=9Ccode first=E2=80=9D UEFI s= pec
contribution I did this with the PPI that added up gettin= g added.

The new audio protocol s= hould be generic, only its implementation
in
qu= estion should be virtio specific.

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

Thanks
Laszlo



<= br class=3D"">
Thanks,

Nate



*From: *<devel@ed= k2.groups.io <mailto:devel@edk2.groups.io>
<mailto:d= evel@edk2.groups.io <mailto:devel@edk2.groups.io>>
&= lt;mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>&= gt;>> on
behalf
of "Andrew Fish via group= s.io <http://groups.io/>
<http://groups.io/ <http= ://groups.io/>> <http://groups.io/
<http://groups= .io/>
<http://groups.io/ <http://groups.io/>>&= gt;"
<afish=3Dapple.com@groups.io <mailto:afish=3Dapple= .com@groups.io>
<mailto:afish=3Dapple.com@groups.io
<mailto:afish=3Dapple.com@groups.io>>
<= ;mailto:apple.com@groups.io <mailto:apple.com@groups.io>
<mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>= >
*Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.= groups.io>
<mailto:devel@edk2.groups.io <mailto:deve= l@edk2.groups.io>>
<mailto:devel@edk2.groups.io <= mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.= io <mailto:devel@edk2.groups.io>>>"
<devel@edk= 2.groups.io <mailto:devel@edk2.groups.io>
<mailto:de= vel@edk2.groups.io <mailto:devel@edk2.groups.io>>
&l= t;mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>&= gt;>>,
"afish@apple.com <mailto:afish@apple.com> = <mailto:afish@apple.com
<mailto:afish@apple.com>>= <mailto:afish@apple.com
<mailto:afish@apple.com><mailto:afish@apple.com <mailto:afish@apple.com>>&g= t;"
<afish@apple.com <mailto:afish@apple.com> <ma= ilto:afish@apple.com
<mailto:afish@apple.com>>
<mailto:afish@apple.com <mailto:afish@apple.com>
<mailto: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>
<mailto:devel@edk2.groups.io <= ;mailto:devel@edk2.groups.io>>
<mailto:devel@edk2.gr= oups.io <mailto:devel@edk2.groups.io>
<mailto:devel@= edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
"harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.co= m>>
<mailto:harlydavidsen@gmail.com <mailto:harly= davidsen@gmail.com>
<mailto:harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>>>"
&l= t;harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.co= m>>
<mailto:harlydavidsen@gmail.com <mailto:harly= davidsen@gmail.com>
<mailto:harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>>>>
*Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
<= ;mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelro= drigues.machado@gmail.com>>
<mailto:rafaelrodrigues.= machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.co= m>
<mailto: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
<ha= rlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
= <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>&g= t;
<mailto:harlydavidsen@gmail.com <mailto:harlydavidse= n@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto= :harlydavidsen@gmail.com>>>
 <mailto:harlyda= vidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<m= ailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>><mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gma= il.com>
<mailto:harlydavidsen@gmail.com
&= lt;mailto:harlydavidsen@gmail.com>>>>>
wrote:<= br class=3D"">


 I'm wonder= ing where exactly I should add the VirtIO sound
protocol.
I
 just familiarized myself with the build sy= stem and am about to
test
it
&nbs= p;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=E2=80=99d match the patter of = OVMF [1] and use
OvmfPkg/VirtioSoundDxe/. Maybe even use one = of the other drivers
as
a
templat= e.



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 wou= ld mean we put the Protocol definition in
MdePkg/Include/Prot= ocol, but we don=E2=80=99t want to do that before it is
stand= ardized as that causes compatibility issues. So this is a
=E2= = =80=9Ccode
first project=E2=80=9D (code prototype and then c= ontribute to the UEFI
Forum
for
i= nclusion in the specification) so we need to follow some code
first
rules that I don=E2=80=99t remember of the top of my h= ead? So why not
start
out
the pro= tocol 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 blo= cked.



We can hav= e a conversation on the mailing list about better places
toput stuff, and it should be easy enough to move stuff around i= f
everything else is working.


[1] find OvmfPkg  -iname '*Virtio*.inf'
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.in= f

OvmfPkg/VirtioScsiDxe/VirtioScsi.inf

OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceL= ib.inf

OvmfPkg/Library/VirtioLib/VirtioLib.inf=

OvmfPkg/VirtioGpuDxe/VirtioGpu.inf

OvmfPkg/VirtioBlkDxe/VirtioBlk.inf

OvmfPkg/Virtio10Dxe/Virtio10.inf

Ov= mfPkg/VirtioNetDxe/VirtioNet.inf

OvmfPkg/Virti= oRngDxe/VirtioRng.inf



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

EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_= TYPE
 =3D UEFI_APPLICATION

=

Thanks,



Andrew Fish






 On 3/3= 0/21, Ethin Probst via groups.io <http://groups.io/>
&l= t;http://groups.io/ <http://groups.io/>>
<http://= groups.io/ <http://groups.io/> <http://groups.io/
&l= t;http://groups.io/>>>
<http://groups.io/ <htt= p://groups.io/> <http://groups.io/
<http://groups.io= />> <http://groups.io/ <http://groups.io/>
<= ;http://groups.io/ <http://groups.io/>>>>
&nbs= p;<harlydavidsen=3Dgmail.com@groups.io
<mailto:harlydav= idsen=3Dgmail.com@groups.io>
<mailto:harlydavidsen=3Dgm= ail.com@groups.io
<mailto:harlydavidsen=3Dgmail.com@groups= .io>>
<mailto:gmail.com@groups.io <mailto:gmail.c= om@groups.io>
<mailto:gmail.com@groups.io <mailto:gm= ail.com@groups.io>>>
 <mailto:harlydavidsen = <mailto:harlydavidsen>=3Dgmail.com@groups.io
<mailto= :gmail.com@groups.io>
<mailto:gmail.com@groups.io <m= ailto:gmail.com@groups.io>>
<mailto:gmail.com@groups= .io <mailto:gmail.com@groups.io>
<mailto:gmail.com@g= roups.io <mailto:gmail.com@groups.io>>>>>
w= rote:

     I agree. P= lus, 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
sid= e
     project and, though learning = from other code examples from
OSes
is
     fun, I have to say that learning from = the firmware code like
from
   &= nbsp; SeaBIOS has been some of the most enlightening and
interesting
times
    &nbs= p;thus far.
     Thanks for the link= to your code, Rafael; once I get virtIO
support
     in, I can work on HDA support, though I mig= ht tackle USB
support
    &= nbsp;second and HDA third. We'll see, but VirtIO definitely is
coming
     first.
<= br class=3D"">     As I said before, I look forwar= d to working with all of you
     wo= nderful
     people!
<= br class=3D"">     On 3/30/21, Rafael Rodrigues Ma= chado
     <rafaelrodrigues.macha= do@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>=
<mailto:rafaelrodrigues.machado@gmail.com
&= lt;mailto:rafaelrodrigues.machado@gmail.com>>
<mailt= o:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigue= s.machado@gmail.com>
<mailto:rafaelrodrigues.machado@gm= ail.com
<mailto:rafaelrodrigues.machado@gmail.com>>&= gt;
     <mailto:rafaelrodrigues.= machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.co= m>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>
&= lt;mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafael= rodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.ma= chado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com&= gt;>>>>
     wrote:

        &n= bsp;This would be amazing so people can continue my work
rela= ted
to
      &nbs= p;  accessibility at BIOS. Something desired by the blind
people
        = ; since the
       &n= bsp; 90's
       &nbs= p; Just for reference, this is what I have done:


https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_= Accessibility
<https://github.com/RafaelRMachado/Msc_UefiH= da_PreOs_Accessibility>
<https://github.com/RafaelRMach= ado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/Ra= faelRMachado/Msc_UefiHda_PreOs_Accessibility>>
<http= s://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility><= br class=3D""><https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Acces= sibility
<https://github.com/RafaelRMachado/Msc_UefiHda_Pr= eOs_Accessibility>>>

  &nbs= p;      Thanks
  &nbs= p;      Rafael

&= nbsp;        Em seg, 29 de mar de 2= 021 20:24, Ethin Probst
      &= nbsp;  <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail= .com>
<mailto:harlydavidsen@gmail.com <mailto:harlyd= avidsen@gmail.com>>
<mailto:harlydavidsen@gmail.com = <mailto:harlydavidsen@gmail.com>
<mailto:harlydavids= en@gmail.com
<mailto:harlydavidsen@gmail.com>>>&g= t;
         escr= eveu:


    &= nbsp;        Hello everyone,

        &nbs= p;    This is the first time I've ever contributed toEDK2.
As
    &= nbsp;        part of GSoC
           &n= bsp; 2021, I have submitted a proposal to implement a
UE= FI
         &nbs= p;   audio output
    &nbs= p;        protocol that will utiliz= e the VirtIO sound driver.
I've
  &nb= sp;          already
           = ;  submitted a draft proposal, and apologize if I've
done
         =     things out of
    = ;         order. This is my fi= rst time doing GSoC 2021, and
     &= nbsp;       contributing to EDK2
           &n= bsp; felt like a really fun thing to do!

=             &nb= sp;I look forward to working with you guys on this and
any          &nb= sp;  future projects!
     = ;        :-)

           &n= bsp; --
        =      Signed,
    = ;         Ethin D. Probst









 = ;    --
     Sig= ned,
     Ethin D. Probst







 --
 Signed, Ethin D. Probst










--
Signed,
Ethin D. Probst








--
Signed,
Ethin D. Prob= st



=



--=
Signed,
Ethin D. Probst








--
Signed,<= br class=3D"">Ethin D. Probst



--
Sig= ned,
Ethin D. Probst



--Apple-Mail=_607152E1-DE0D-4FFF-AD29-4D6000A2A009--