On Mon, Dec 1, 2014 at 3:48 PM, Alexandre Courbot <[email protected]> wrote: > On Mon, Dec 1, 2014 at 3:38 PM, Terje Bergström <[email protected]> wrote: >> On 29.11.2014 10:44, Alexandre Courbot wrote: >>> On Fri, Nov 28, 2014 at 9:09 PM, Roy Spliet <[email protected]> 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? _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
