On 29/01/18 09:51, John Hubbard wrote: > On 01/28/2018 04:05 PM, Martin Peres wrote: >> On 29/01/18 01:24, Martin Peres wrote: >>> On 28/11/17 07:32, John Hubbard wrote: >>>> On 11/23/2017 02:48 PM, Martin Peres wrote: >>>>> On 23/11/17 10:06, John Hubbard wrote: >>>>>> On 11/22/2017 05:07 PM, Martin Peres wrote: >>>>>>> Hey, >>>>>>> >>>>>>> Thanks for your answer, Andy! >>>>>>> >>>>>>> On 22/11/17 04:06, Ilia Mirkin wrote: >>>>>>>> On Tue, Nov 21, 2017 at 8:29 PM, Andy Ritger <arit...@nvidia.com> >>>>>>>> wrote: >>>>>>>> Martin's question was very long, but it boils down to this: >>>>>>>> >>>>>>>> How do we compute the correct values to write into the e114/e118 pwm >>>>>>>> registers based on the VBIOS contents and current state of the board >>>>>>>> (like temperature). >>>>>>> >>>>>>> Unfortunately, it can also be the e11c/e120 couple, or 0x200d8/dc on >>>>>>> GF119+, or 0x200cd/d0 on Kepler+. >>>>>>> >>>>>>> At least, it looks like we know which PWM controler we need to drive, so >>>>>>> I did not want to muddy the water even more by giving register >>>>>>> addresses, rather concentrating on the problem at hand: How to compute >>>>>>> the duty value for the PWM controler. >>>>>>> >>>>>>>> >>>>>>>> We generally do this right, but appear to get it extra-wrong for >>>>>>>> certain GPUs. >>>>>>> >>>>>>> Yes... So far, we are always safe, but users tend to mind when their >>>>>>> computer sound like a jumbo jet at take off... Who would have thought? >>>>>>> :D >>>>>>> >>>>>>> Anyway, looking forward to your answer! >>>>>>> >>>>>>> Cheers, >>>>>>> Martin >>>>>> >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> One of our firmware engineers thinks that this looks a lot like PWM >>>>>> inversion. >>>>>> For some SKUs, the interpretation of the PWM duty cycle is inverted. >>>>>> That >>>>>> would probably make it *very* difficult to find a sensible algorithm >>>>>> that >>>>>> covered all the SKUs, given that some are inverted and others are not. >>>>>> >>>>>> For the noisy GPUs, a very useful experiment would be to try inverting >>>>>> it, >>>>>> like this: >>>>>> >>>>>> pwmDutyCycle = pwmPeriod - pwmDutyCycle; >>>>>> >>>>>> ...and then see if fan control starts behaving closer to how you've >>>>>> actually >>>>>> programmed it. >>>>>> >>>>>> Would that be easy enough to try out? It should help narrow down the >>>>>> problem at least. >>>>>> >>>>> >>>>> Hey John, >>>>> >>>>> Unfortunately, we know about PWM inversion, and one can know which mode >>>>> to use based on the GPIO entry associated to the fan (inverted). We have >>>>> had support for this in Nouveau for a long time. At the very least, this >>>>> is not the problem on my GF108. >>>>> >>>>> I am certain that the problem I am seeing is related to this vbios table >>>>> I wrote about (BIT P, offset 0x18). It is used to compute what PWM duty >>>>> I should use for both 0 and 100% of the fan speed. >>>>> >>>>> Computing the value for 0% fan speed is difficult because of >>>>> non-continuous nature of some of the functions[1], but I can always >>>>> over-approximate. However, I failed to accurately compute the duty I >>>>> need to write to get the 100% fan speed (I have cases where I greatly >>>>> over-estimate it...). >>>>> >>>>> Could you please check out the vbios table I am pointing at? I am quite >>>>> sure that your documentation will be clearer than my babbling :D >>>> >>>> Yes. We will check on this. There has been some productive discussion >>>> internally, but it will take some more investigation. >>>> >>>> thanks, >>>> John Hubbard >>> >>> Have the productive discussions panned out? > > Yes, we concluded our discussions, and decided that I should study the > situation > and write some documentation. I just finished my research and writeup late > last Friday, > though, so my colleagues haven't had a chance to review it. Not to put undue > pressure on them, but I'm hoping that will go quickly now. The long pole is > done. :) > > I was going to wait until the review was done, to respond, but I wanted to > ACK > this and to let you know that I do realize that the tables below are not > directly > answering your question. > > (What happened here is: the new tables below are not actually what I've > personally been working on; they just happen to be a very good set of > supporting > documentation in the exact same area. One of our teammates was already > working > on these independently, and managed to get them released.)
Thanks for the information and your work, it is greatly appreciated. No need to hurry, I will be away from home for 2 weeks. Thanks, Martin > > thanks, > _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau