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

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.

Terje

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.  If you are not the intended recipient, please contact the sender
by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

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?

On Mon, Dec 1, 2014 at 3:48 PM, Alexandre Courbot <gnurou at gmail.com>
wrote:
> 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?
Mmm, re-reading your reply I realize you only mention the CVB table.
But since the CVB and frequencies must match anyway, I suppose it
applies to the frequencies table as well, am I correct?

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!