From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by mx.groups.io with SMTP id smtpd.web08.6784.1618363232115586083 for ; Tue, 13 Apr 2021 18:20:32 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=pJN2QbLm; spf=pass (domain: gmail.com, ip: 209.85.218.53, mailfrom: harlydavidsen@gmail.com) Received: by mail-ej1-f53.google.com with SMTP id u17so28864125ejk.2 for ; Tue, 13 Apr 2021 18:20:31 -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=oZ0AoSk3HHjbKLANtSA1GqJHROuPki/2bSreha7K5zc=; b=pJN2QbLmlRa28PCav0FsEfLA+RMaQTFi0W6UUeLHQSD9CC2aIibJTWKUALsI8s0cJC D7fuj9CJIJHT28as55DqWRPnuN3K83wgJHV818e9HKQ3Vl7tBqidPGH+oClmp8IwpUqY p4XVmeruUndZOTPQ8ilNMa20jIu1gtA94a5+C6uk4nnTzK4T96yZosqVGSg61+lkgMeu m+uOnAn6cgNDrMAIE8132aTzvKm8AktAmXnvfjSJLrY85RWnNXbxjXYhB+Pei6UpWFdb ce/O8VcmyTGlvNZ3VjoC3Yn8RrNB6hhGAMxadBsLdMmS5XtymIx1YPIuXLfRIJRDgp3k n1gQ== 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=oZ0AoSk3HHjbKLANtSA1GqJHROuPki/2bSreha7K5zc=; b=rhWqyZ7NA1x9c1bvlj7oAkfAG+xIhkjINIFLRiKjeIkIxAUfX5Cr6tKqubwFparcQj p6GC6g5xs2g5iPIRQDRluMacZAkmj+BW00CUA+jSJn4oPEAl+/cZwSyOhDwmXgzUvUqt tMIOrO2cgng9CFjZgQIdlnYCwbRbXFWmtitc7W6UUFLaIilda49uxPw5rB62kUY1+Goo vsN5sTcseTCvW90xkwNhdBiSSATztWqftpntd0j7nop+gzf91OSrIr8yXwZaORrW0xot leI7uOJUVkOYg7V5GJkQ3CJZbV4V5CA2THSseR6jkI1C5OxYIM49X41EEVRc0Ezl7cTZ JzvQ== X-Gm-Message-State: AOAM531HLWR9fpBWLyzF+d3p6F0MI828OeCNmXG+7+E/32gk7V8aQa6c HAF1AM0/BDZCfavYfn6SdOXd0e9Ka8SuuCk8BqgRTILaLn5pug== X-Google-Smtp-Source: ABdhPJwJOZL63t304MQ+/gjB5x12DgJHnEAVIMaVpUqFGFdajlH5qGml4skaip9GO/lm671gR3uQak5oMHxls772T2Q= X-Received: by 2002:a17:906:130a:: with SMTP id w10mr19856494ejb.71.1618363230334; Tue, 13 Apr 2021 18:20:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab4:9a0a:0:0:0:0:0 with HTTP; Tue, 13 Apr 2021 18:20:29 -0700 (PDT) In-Reply-To: <16758FB6436B1195.32393@groups.io> References: <16713E6D64EE917D.25648@groups.io> <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> <16758FB6436B1195.32393@groups.io> From: "Ethin Probst" Date: Tue, 13 Apr 2021 20:20:29 -0500 Message-ID: Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) To: devel@edk2.groups.io, harlydavidsen@gmail.com Cc: Andrew Fish , Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, so looking at the EDK2 driver developers guide, here are my thoughts: - 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. 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? On 4/13/21, Ethin Probst via groups.io wrote: > 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 th= e >> 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 >> UEFI >> drivers: >> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Write= r%27s-Guide >> >> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protoco= l/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 > >>> 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=E2=80=99d 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=E2= = =80=99ve >>>> got >>>> a >>>> lot of feedback that folks read or search the mailing list looking fo= r >>>> 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, fe= el >>>>> 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 a= nd >>>>>>> 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 i= n >>>>>> 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 a= s >>>>>>> a >>>>>>> template. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The protocol is more of a public thing. I think eventually we woul= d >>>>>>> like >>>>>>> to publish the protocol in the UEFI Spec (I can help with that par= t) >>>>>>> and >>>>>>> that would mean we put the Protocol definition in >>>>>>> MdePkg/Include/Protocol, but we don=E2=80=99t want to do that befo= re 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 fir= st >>>>>>> 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 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 -- *.in= f >>>>>>> | >>>>>>> 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 ED= K2 >>>>>>> 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 lik= e >>>>>>> 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 >>>>>>> >>>>>> >>>>>>> >>>>>> > >>>>>>> >>>>>> >>>>>>> >>>>>> >>> >>>>>>> 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 EDK= 2. >>>>>>> As >>>>>>> part of GSoC >>>>>>> 2021, I have submitted a proposal to implement a UE= FI >>>>>>> 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 >>> >>> >>> >> >> > > > -- > Signed, > Ethin D. Probst > > >=20 > > > --=20 Signed, Ethin D. Probst