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

[Roy Spliet]

Op 01-12-14 om 07:48 schreef 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?
>
If the table is per-chip, then I certainly agree!