[Nouveau] [RESEND PATCH nouveau 3/3] volt: add support for GK20A

[Alexandre Courbot]

On Mon, Dec 1, 2014 at 3:38 PM, Terje Bergström <tbergstrom at nvidia.com> wrote:
> On 29.11.2014 10:44, Alexandre Courbot wrote:
>> On Fri, Nov 28, 2014 at 9:09 PM, Roy Spliet <seven at nimrod-online.com> wrote:
>>> I'm not sure if I completely understand your reply, so forgive me if I am
>>> stating some obvious things:
>>> The reason why I brought this up is because, the way I see it, DTS is the
>>> replacement for (V)BIOS on ARM platforms, giving a set of parameters that
>>> drivers (nouveau) can use for that particular instance (the Tegra K1 SoC) of
>>> some more generic IP (gk20a). All the other devices nouveau supports have a
>>> VBIOS to describe this kind of information to us, hence we haven't seen this
>>> before. For CPUs there are plenty of examples though of such params defined
>>> in DT: in arch/arm/boot/dts/ : imx6qdl.dtsi documents the min and max volt
>>> for regulators, while the CPUs have a little freq<->volt mapping in
>>> imx6q.dtsi. GPUs are new in a sense that NVIDIA is the first to actively
>>> support upstream development (thanks!)
>> Thanks for raising this point. I agree with your interpretation that
>> DT is comparable to the VBIOS in desktop GPUs. The question then
>> becomes whether this data can vary between different GK20A-using
>> boards (and in this case this should probably be part of DT) or not
>> (in which case I would advocate having this static information in the
>> driver itself). Since I don't expect different GK20A-using chips to
>> require different voltage for given frequencies, my gut feeling for
>> the moment is that having this information in the driver is fine. I
>> have added a few other NVIDIA people to gather thoughts.
>
> The voltage<->frequency relationship is per chip, not per board. We read
> the chip id at runtime, and programmatically determine the DVFS steps
> based on that. CVB table contains the parameters for the algorithm.
>
> I think the table belongs in the driver. The table is not per board, and
> the values in CVB table do not describe hardware, but parameters to an
> algorithm.

In that case I also think it would make more sense (and make things
easier) to have these tables in the driver. Roy, do you have any
objection?