From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by mx.groups.io with SMTP id smtpd.web12.5729.1618357653558753450 for ; Tue, 13 Apr 2021 16:47:33 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rQ2sFrK4; spf=pass (domain: gmail.com, ip: 209.85.208.47, mailfrom: harlydavidsen@gmail.com) Received: by mail-ed1-f47.google.com with SMTP id m3so21462998edv.5 for ; Tue, 13 Apr 2021 16:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LBUHLC2zFNu85EZ/cE970e+20PTCxEkX51+NuIEvuc0=; b=rQ2sFrK45WnoV4eRwGM3QTkf2mqelrbUDVRS2YaMF0SfD3wfj43U7WVzNXgdPMKfxJ 17Bo+Ek3f1MrptVRkPz0WK8AJmM9r5eRXsC7fJwJL759ILReAt2lhmgXzRFDSjgIIjxf nGgpHapiwGHZ0SUk+LstQtk3P69mxt2fvQgHpPXgtdR0voutviXQj9EM3ySp3onfOqLx /w1PLqwL4kEOix0vF9fE2SDpiQsoqSpKb8GTMAkzs8/aQS+Cyxq5lzwuMDMa4AI8efDe yZxmllCpBGBhsfcFIIoi27WLYipO0OuwDYe+TgXmu6ytcGI85Y5gQfqDNYeCRbsTxrVL kX4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LBUHLC2zFNu85EZ/cE970e+20PTCxEkX51+NuIEvuc0=; b=FESUB2rBfW1aPnT/sCYKD5B71+dd9i0K3ASdB29VIW14nAinZJjl+OK/pRn0Cs8JkX 54jwFdJ8QU4Pnlk2hQkC88Ryjxr6Jl//ttIKhpw/ecJirUFarEn7yUuNSqpAh84GEtmk SrMOOeSusndnMBgQhMYzsX2PZCJuOpVkhq/70pnhAPijgUtd/ugleXC7lQ/bluhRkt1i YGYI6mhUgJpXb0OspXOasxj+Mhlr89Pvv4balu3pATCymJNefFyveLncXT6g9n/Shm8H dsnvtASj0rjspWUwmFRYqv5c2aYctGH0onJZPP4bcSJc2BLPfqpg58kyuK9M3fWFJgh/ KNog== X-Gm-Message-State: AOAM532lacn2anQFpdwqfZn1n5CUv0RdPew7TJj6dVENvooal53giP5N V0eA+AIBzvUE3oV+DV070UXdjUaghxVEn4js4T4= X-Google-Smtp-Source: ABdhPJxL2VvlU8PUKvzoxUdyrQ/LFuiXtCOa2k88KHSOUK9bRMSbFC+4UnMGOa445VLfhAZhgswA986vNv+1XOnfE60= X-Received: by 2002:aa7:dd98:: with SMTP id g24mr37719224edv.75.1618357652005; Tue, 13 Apr 2021 16:47:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab4:9a0a:0:0:0:0:0 with HTTP; Tue, 13 Apr 2021 16:47:31 -0700 (PDT) In-Reply-To: References: <16713E6D64EE917D.25648@groups.io> <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> From: "Ethin Probst" Date: Tue, 13 Apr 2021 18:47:31 -0500 Message-ID: Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) To: Andrew Fish Cc: devel@edk2.groups.io, Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, 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 may just ahve to do my building on Linux and not Windows -- unless the Bug -- 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. On 4/13/21, Andrew Fish wrote: > > >> On Apr 13, 2021, at 9:53 AM, Ethin Probst >> 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). >> > > 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. > > For a device driver the general UEFI model is for the Entry point of the > driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported() func= tion > 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: > https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer= %27s-Guide > > [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol= /DriverBinding.h#L157 > > Thanks, > > Andrew Fish > >> 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 > wrot= e: >>> Leif, >>> >>> Since I have put some brain cells around this area in the past I can b= e >>> the >>> backup and help out too. >>> >>> I=E2=80=99d also point out if you are having issues building or have g= eneral >>> 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 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 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, fee= l >>>> free to spam me with any remaining/new questions. >>>> >>>> / >>>> Leif >>>> >>>> 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 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 >>>> >> >>>> wrote: >>>>> On 03/31/21 08:41, Nate DeSimone wrote: >>>>>> Another option is to put the protocol definition in MdeModulePkg an= d >>>>>> mark it with the EDKII_ prefix. For my last =E2=80=9Ccode first=E2= =80=9D 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: * >>>>>> >> 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) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mar 30, 2021, at 5:01 PM, Ethin Probst >>>>> >>>>>> > >>>>>> >>>>>> >>> >>>>>> 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=E2=80=99d 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=E2=80=99t want to do that befor= e 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 U= EFI Forum >>>>>> for >>>>>> inclusion in the specification) so we need to follow some code firs= t >>>>>> rules that I don=E2=80=99t remember of the top of my head? So why n= ot 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 f= or >>>>>> 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 >>>>>> =3D UEFI_APPLICATION >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> Andrew Fish >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 3/30/21, Ethin Probst via groups.io >>>>>> > >>>>>> >>>>> >> >>>>>> >>>>> >>>>> > >>>>>> =3Dgmail.com@groups.= io >>>>>> >>>>>> >>> wrote: >>>>>> >>>>>> I agree. Plus, it gives me a chance to finally learn the EDK= 2 >>>>>> 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 interesti= ng >>>>>> 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 >>>>>> >>>>> >>>>>> >>>>> > >>>>>> >>>>> >>>>>> >>>>> >>> >>>>>> 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 >>>>>> >>>>>> >>>>> = > >>>>>> >>>>>> Thanks >>>>>> Rafael >>>>>> >>>>>> Em seg, 29 de mar de 2021 20:24, Ethin Probst >>>>>> >>>>>> >> >>>>>> 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 UEF= I >>>>>> audio output >>>>>> protocol that will utilize the VirtIO sound driver. >>>>>> I've >>>>>> already >>>>>> submitted a draft proposal, and apologize if I've do= ne >>>>>> 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 >> >> >>=20 > > --=20 Signed, Ethin D. Probst