On 21 May 2015 at 16:03, Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
> On Fri, May 15, 2015 at 2:37 PM, Ben Skeggs <skeggsb@xxxxxxxxx> wrote:
>> On 12 May 2015 at 19:04, Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
>>> Hi Ben,
>>>
>>> On Fri, May 1, 2015 at 8:01 AM, Ben Skeggs <skeggsb@xxxxxxxxx> wrote:
>>>> On 13 April 2015 at 20:42, Alexandre Courbot <acourbot@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
