On 12 May 2015 at 19:04, Alexandre Courbot <gnurou at gmail.com> wrote:> Hi Ben, > > On Fri, May 1, 2015 at 8:01 AM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 13 April 2015 at 20:42, Alexandre Courbot <acourbot at nvidia.com> wrote: >>> Ben, I guess our main remaining concern with this patch is how it should >>> integrate wrt. the existing PMU code. Since it is designed to interact with >>> the NVIDIA firmware, maybe we should use a different base code, or do you >>> think we can somehow share code and data structures? >> Hey Alexandre, >> >> Sorry for the delay in responding to this. > > It is my turn to apologize - I was (well still am, technically :)) on > holidays and have just started unpiling my inbox... > >> >> My original thinking with transitioning to use NVIDIA's firmware was >> that I'd modify our firmware interfaces to match yours, and share the >> code. I haven't started on any of this yet due to not having any word >> on how you guys will be shipping the images, etc. It would be nice to >> have some communication on these things :) > > Indeed. For the first time with Maxwell GPUs, NVIDIA-provided firmware > will be required for GPUs to operate properly. This raises several > questions: > > - Should the firmware be released under /lib/firmware/nouveau or > /lib/firmware/nvidia ? (this directory already exists for Tegra USB > firmware and makes more sense to me, since the firmware is not > Nouveau-specific)I think /lib/firmware/nvidia makes sense here too.> - For GPCCS/FECS firmware, should we release the netlist "pack" file > or adopt the same format as Nouveau does? (1 file per firmware) > - Should we keep the current files names (e.g. nvxx_fucxxxx[cd]), or > try to switch to more meaningful ones?I'd actually prefer to have the entire netlists bundled, that gives us updated reg/ctx production values too as you guys tweak/update them for hw bugs (etc). They're also nicer in that you get a single bundle of everything that's required for that chipset+engine. I don't have too much opinion on naming. The current model of nv{CHIPSET}_{UCODE_TYPE}{REGISTER_BASE}[CODE,DATA] was just nice and convenient to snprintf into a buffer :)> - What about signature files that are required for secure boot?As with above, if it's possible to ship them in a single file with the ucode that it belongs to, that'd be ideal. It's not a huge deal though.> - Knowing that NVIDIA's firmware ABI is a (very slowly) moving target, > it is worth to aim at ABI compatibility, or should we assume different > paths for Nouveau and NVIDIA firmware? If ABI incompatibilities are > introduced in the way, how do we handle versioning?For incompatible changes, I think appending a -VERSION to each firmware blob is probably the simplest approach. The driver can select the necessary codepath based on what it finds (probably trying newer versions first, obviously).> > All these issues make me tend towards having a separate handling of > NVIDIA-released firmware (location, format, and ABI). It will also > make the firmware easier to release if conversions are not necessary > on the way out. What are your thoughts on this?I'm not entirely set here, either way. I somewhat think that initially I should adapt our interfaces to match, and a keep single code path as long as we can. A lot of the changes so far have seemed minor enough we could stick conditionals on firmware version, and if fw changes come along that warrant a radical change in handling from the host, we can abstract it away then. But, I'm open to other suggestions :) Ben.> >> I'm suspecting you won't be wanting to modify our falcon assembly, so >> I guess I'll set aside some time to use this patch as a base and >> transition our ucode to boot using it? Then you guys can build more >> stuff on top of that. I'm also happy to let you modify our ucode if >> you wish :) > > There may be legal issues with us touching the Nouveau firmware. But > as I stated above, the first question is do we want to bother with > this compatiblity at all?
On Fri, May 15, 2015 at 2:37 PM, Ben Skeggs <skeggsb at gmail.com> wrote:> On 12 May 2015 at 19:04, Alexandre Courbot <gnurou at gmail.com> wrote: >> Hi Ben, >> >> On Fri, May 1, 2015 at 8:01 AM, Ben Skeggs <skeggsb at gmail.com> wrote: >>> On 13 April 2015 at 20:42, Alexandre Courbot <acourbot at nvidia.com> wrote: >>>> Ben, I guess our main remaining concern with this patch is how it should >>>> integrate wrt. the existing PMU code. Since it is designed to interact with >>>> the NVIDIA firmware, maybe we should use a different base code, or do you >>>> think we can somehow share code and data structures? >>> Hey Alexandre, >>> >>> Sorry for the delay in responding to this. >> >> It is my turn to apologize - I was (well still am, technically :)) on >> holidays and have just started unpiling my inbox... >> >>> >>> My original thinking with transitioning to use NVIDIA's firmware was >>> that I'd modify our firmware interfaces to match yours, and share the >>> code. I haven't started on any of this yet due to not having any word >>> on how you guys will be shipping the images, etc. It would be nice to >>> have some communication on these things :) >> >> Indeed. For the first time with Maxwell GPUs, NVIDIA-provided firmware >> will be required for GPUs to operate properly. This raises several >> questions: >> >> - Should the firmware be released under /lib/firmware/nouveau or >> /lib/firmware/nvidia ? (this directory already exists for Tegra USB >> firmware and makes more sense to me, since the firmware is not >> Nouveau-specific) > I think /lib/firmware/nvidia makes sense here too. > >> - For GPCCS/FECS firmware, should we release the netlist "pack" file >> or adopt the same format as Nouveau does? (1 file per firmware) >> - Should we keep the current files names (e.g. nvxx_fucxxxx[cd]), or >> try to switch to more meaningful ones? > I'd actually prefer to have the entire netlists bundled, that gives us > updated reg/ctx production values too as you guys tweak/update them > for hw bugs (etc). They're also nicer in that you get a single bundle > of everything that's required for that chipset+engine.Good for me - actually that's the solution I implemented first before deciding to go "à la Nouveau". ;) Some extra code will be needed, but nothing crazy, and we will limit that feature to these chips for which NVIDIA officially provides the firmware.> I don't have too much opinion on naming. The current model of > nv{CHIPSET}_{UCODE_TYPE}{REGISTER_BASE}[CODE,DATA] was just nice and > convenient to snprintf into a buffer :)Since the firmware will be provided by us, shall we store it into nvidia/<chip>/gpcfe.bin on linux-firmware?>> - What about signature files that are required for secure boot? > As with above, if it's possible to ship them in a single file with the > ucode that it belongs to, that'd be ideal. It's not a huge deal > though.So here we actually have several files - it is kind of a mess actually. However I could probably merge them into a single netlist file like we did for the GPC/FE CS code.>> - Knowing that NVIDIA's firmware ABI is a (very slowly) moving target, >> it is worth to aim at ABI compatibility, or should we assume different >> paths for Nouveau and NVIDIA firmware? If ABI incompatibilities are >> introduced in the way, how do we handle versioning? > For incompatible changes, I think appending a -VERSION to each > firmware blob is probably the simplest approach. The driver can > select the necessary codepath based on what it finds (probably trying > newer versions first, obviously).I agree. Hopefully we won't have too much of this.>> All these issues make me tend towards having a separate handling of >> NVIDIA-released firmware (location, format, and ABI). It will also >> make the firmware easier to release if conversions are not necessary >> on the way out. What are your thoughts on this? > I'm not entirely set here, either way. I somewhat think that > initially I should adapt our interfaces to match, and a keep single > code path as long as we can. A lot of the changes so far have seemed > minor enough we could stick conditionals on firmware version, and if > fw changes come along that warrant a radical change in handling from > the host, we can abstract it away then. > > But, I'm open to other suggestions :)Right now my main concern is to get secure boot support in, and the shortest path seems to be to not care about ABI compatibility between Nouveau and NV firmwares (at least for PMU). Basically I am hoping that you will agree to proceed this way in a first time. ^_^
On 21 May 2015 at 16:03, Alexandre Courbot <gnurou at gmail.com> wrote:> On Fri, May 15, 2015 at 2:37 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 12 May 2015 at 19:04, Alexandre Courbot <gnurou at gmail.com> wrote: >>> Hi Ben, >>> >>> On Fri, May 1, 2015 at 8:01 AM, Ben Skeggs <skeggsb at gmail.com> wrote: >>>> On 13 April 2015 at 20:42, Alexandre Courbot <acourbot at nvidia.com> wrote: >>>>> Ben, I guess our main remaining concern with this patch is how it should >>>>> integrate wrt. the existing PMU code. Since it is designed to interact with >>>>> the NVIDIA firmware, maybe we should use a different base code, or do you >>>>> think we can somehow share code and data structures? >>>> Hey Alexandre, >>>> >>>> Sorry for the delay in responding to this. >>> >>> It is my turn to apologize - I was (well still am, technically :)) on >>> holidays and have just started unpiling my inbox... >>> >>>> >>>> My original thinking with transitioning to use NVIDIA's firmware was >>>> that I'd modify our firmware interfaces to match yours, and share the >>>> code. I haven't started on any of this yet due to not having any word >>>> on how you guys will be shipping the images, etc. It would be nice to >>>> have some communication on these things :) >>> >>> Indeed. For the first time with Maxwell GPUs, NVIDIA-provided firmware >>> will be required for GPUs to operate properly. This raises several >>> questions: >>> >>> - Should the firmware be released under /lib/firmware/nouveau or >>> /lib/firmware/nvidia ? (this directory already exists for Tegra USB >>> firmware and makes more sense to me, since the firmware is not >>> Nouveau-specific) >> I think /lib/firmware/nvidia makes sense here too. >> >>> - For GPCCS/FECS firmware, should we release the netlist "pack" file >>> or adopt the same format as Nouveau does? (1 file per firmware) >>> - Should we keep the current files names (e.g. nvxx_fucxxxx[cd]), or >>> try to switch to more meaningful ones? >> I'd actually prefer to have the entire netlists bundled, that gives us >> updated reg/ctx production values too as you guys tweak/update them >> for hw bugs (etc). They're also nicer in that you get a single bundle >> of everything that's required for that chipset+engine. > > Good for me - actually that's the solution I implemented first before > deciding to go "à la Nouveau". ;) Some extra code will be needed, but > nothing crazy, and we will limit that feature to these chips for which > NVIDIA officially provides the firmware. > >> I don't have too much opinion on naming. The current model of >> nv{CHIPSET}_{UCODE_TYPE}{REGISTER_BASE}[CODE,DATA] was just nice and >> convenient to snprintf into a buffer :) > > Since the firmware will be provided by us, shall we store it into > nvidia/<chip>/gpcfe.bin on linux-firmware?Sounds fine.> >>> - What about signature files that are required for secure boot? >> As with above, if it's possible to ship them in a single file with the >> ucode that it belongs to, that'd be ideal. It's not a huge deal >> though. > > So here we actually have several files - it is kind of a mess > actually. However I could probably merge them into a single netlist > file like we did for the GPC/FE CS code.If that's possible, that'd be great.> >>> - Knowing that NVIDIA's firmware ABI is a (very slowly) moving target, >>> it is worth to aim at ABI compatibility, or should we assume different >>> paths for Nouveau and NVIDIA firmware? If ABI incompatibilities are >>> introduced in the way, how do we handle versioning? >> For incompatible changes, I think appending a -VERSION to each >> firmware blob is probably the simplest approach. The driver can >> select the necessary codepath based on what it finds (probably trying >> newer versions first, obviously). > > I agree. Hopefully we won't have too much of this. > >>> All these issues make me tend towards having a separate handling of >>> NVIDIA-released firmware (location, format, and ABI). It will also >>> make the firmware easier to release if conversions are not necessary >>> on the way out. What are your thoughts on this? >> I'm not entirely set here, either way. I somewhat think that >> initially I should adapt our interfaces to match, and a keep single >> code path as long as we can. A lot of the changes so far have seemed >> minor enough we could stick conditionals on firmware version, and if >> fw changes come along that warrant a radical change in handling from >> the host, we can abstract it away then. >> >> But, I'm open to other suggestions :) > > Right now my main concern is to get secure boot support in, and the > shortest path seems to be to not care about ABI compatibility between > Nouveau and NV firmwares (at least for PMU). Basically I am hoping > that you will agree to proceed this way in a first time. ^_^If it's really that urgent, my suggestion is to submit the patches as you did previously, keeping them confined to GK20A/GM20B, and I'll do something nicer to support boards in general. Frankly, I'd have had secure boot support in the driver already had NVIDIA played things a little differently... Going forward, I'd like to see NVIDIA not treating the Tegra parts of nouveau as a little black box where anything goes and things are different from the rest of the driver. The chips operate, for the most part, identically to their big siblings... Thanks, Ben.