[Nouveau] [PATCH v4] pmu/gk20a: PMU boot support

[Alexandre Courbot]

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. ^_^