On 21 May 2015 at 18:46, Ben Skeggs <skeggsb@xxxxxxxxx> wrote:
> 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.
Elaborating a bit on that, as it seems unclear reading it back. It's
open-source, don't be afraid of proposing/making changes to things
where you see it's needed, even if it does touch the scary desktop
GPUs :)
Ben.
> 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
