Created attachment 25998 [details]
Dump registers before and after calling RHDSetEngineClock.

You can look at the command table for SetEngineClock and see the algorithm and registers used to compute and set the engine pll.  The AtomDis utility is useful for this.

Created attachment 25999 [details]
All registers changes for different engine clock values

(In reply to comment #2)
> You can look at the command table for SetEngineClock and see the algorithm and
> registers used to compute and set the engine pll.  The AtomDis utility is
> useful for this.

I started with looking on GetEngineClock (should be easier). I can't understand that.

$ ./atomdis 95C4.104D.9035.vga.rom c 30 | grep reg
gives me 2 unique registers:
reg[0180] and reg[01f5]

# rhd_dump -r 0180,0180 01:00.0 && rhd_dump -r 01f4,01f4 01:00.0
gives me:
0x0180: 0x00000000
0x01F4: 0x00000000

So I have no idea how AtomBIOS can calculate that. It uses these 2 registers, but both are always zeroed for me.

Created attachment 26042 [details] [review]
Almost working patch for M82... is misses x10 somewhere

(II) RADEONHD(0): Maybe Engine Clock is 67500
(II) RADEONHD(0): Current Engine Clock: 675000

(II) RADEONHD(0): Attempting to set Engine Clock to 168750
(II) RADEONHD(0): Maybe Engine Clock is 16875
(II) RADEONHD(0): Current Engine Clock: 168750

AtomBIOS tables contain frequencies in muliples of 10kHz.

reg[0180] references values at register location 0x600.

I wouldn't invest too much time in that - I would assume that the power logic is something that may be changed from chip to chip subtly. It's not that we will be changing the frequency on a millisecond basis.

OTOH you may find out that it's actually the same for a whole chipset generation. Who knows.

(In reply to comment #7)
> I wouldn't invest too much time in that - I would assume that the power logic
> is something that may be changed from chip to chip subtly. It's not that we
> will be changing the frequency on a millisecond basis.

Ditto.

Remember that it's still the driver doing the actual register manipulation; AtomBIOS just tells it what to do.

If speed and/or clarity is identified to be an issue, rewriting the AtomBIOS implementation in radeonhd is perhaps a better way. So far, I don't think anyone's considered this to be worth the effort.

Whatever you do with these patches, invested time won't be wasted. I'm doing that to understand the way driver works and slowly I'm getting clue on that :)

I decided to publish my work because I thought you prefer to use registers rather than AtomBIOS in radeonhd... I based my opinion on using registers for PLL/CRTC/etc by radeonhd.

(In reply to comment #9)
> Whatever you do with these patches, invested time won't be wasted. I'm doing
> that to understand the way driver works and slowly I'm getting clue on that :)

I agree that this is a good way to understand the AtomBIOS inner workings, and we definitely could need another guy understanding it - sometimes you just need to know(TM) what actually happens to make something work :-)

> I decided to publish my work because I thought you prefer to use registers
> rather than AtomBIOS in radeonhd... I based my opinion on using registers for
> PLL/CRTC/etc by radeonhd.

Given that AtomBIOS works actually pretty well this is not a *strong* preference now. Still, in quite some regions direct coding is preferred. Power management however is something that can easily change subtly between chips (e.g. delays between register accesses or register access order may change). In these cases using AtomBIOS might be a better idea, however, we don't know yet whether we can do everything we want to with AtomBIOS alone. So your analysis might come in handy later on.

Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so, please move this to the Driver/Radeon component.  

Development of radeonhd has pretty much halted and development focus is on the ati driver.  Please see http://www.x.org/wiki/radeonhd

If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.

(In reply to comment #11)
> Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so,
> please move this to the Driver/Radeon component.  

Sure, radeon uses AtomBIOS as often as possible.


> Development of radeonhd has pretty much halted and development focus is on the
> ati driver.  Please see http://www.x.org/wiki/radeonhd

I know very well.


> If the issue does not exist in the ati driver (or if there is no response to
> this message), this bug will be closed as WONTFIX unless someone contributes a
> patch.

Have you read that bug reports at all? The ones you were replying recently massively.

(In reply to comment #12)
> (In reply to comment #11)
> > Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so,
> > please move this to the Driver/Radeon component.  
> 
> Sure, radeon uses AtomBIOS as often as possible.

Ok, then sending over to the Radeon component.
 
> > If the issue does not exist in the ati driver (or if there is no response to
> > this message), this bug will be closed as WONTFIX unless someone contributes a
> > patch.
> 
> Have you read that bug reports at all? The ones you were replying recently
> massively.

No.  I'm trying to sort through years of neglected logs.  It takes maybe 2-5 minutes to read through each bug report, which means these 120 bugs in radeonhd would take about 5 hours to read though.  If I can cut that down to just 1 hour by having originators comment on them, that's a great savings ... especially considering that 90% of them would get the above comment whether I did it in mass or one at a time.

If you didn't care to move this to the correct component for 2 years, you shouldn't complain that I didn't spend 5 hours reading through all of them in detail.