[Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling)

[Thulasimani, Sivakumar]

Hi All,
	I went through Ville's changes and it seems to be lacking support for our one  main user experience requirement in Android. Which is as follows
"Ux Restrictions:  Flash/flicker should be avoided as much as possible( i.e during unplug of HDMI avoid immediately lowering the CD clock after hotunplug since it will result in flicker on LFP )." 
The display will be turned off eventually (especially considering Android) and would be good to change the CD clock at this point in time rather than immediately on hot unplug. So we have to add to current implementation to modify the behavior or go with the HWC+driver logic described below. 

regards,
Sivakumar

-----Original Message-----
From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf Of Thulasimani, Sivakumar
Sent: Friday, January 16, 2015 9:56 AM
To: Daniel Vetter
Cc: intel-gfx at lists.freedesktop.org; Purushothaman, Vijay A
Subject: Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling)

Thanks for the pointer, let me sync with Ville and get back.


regards,
Sivakumar

-----Original Message-----
From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel Vetter
Sent: Friday, January 16, 2015 1:08 AM
To: Thulasimani, Sivakumar
Cc: intel-gfx at lists.freedesktop.org; Purushothaman, Vijay A; Syrjala, Ville
Subject: Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling)

You realize that Ville has implemented all this already and his patches are only waiting for review?
-Daniel

On Thu, Jan 15, 2015 at 2:50 PM, Thulasimani, Sivakumar <sivakumar.thulasimani at intel.com> wrote:
> Hi,
>
>                 I’ll be working on implementing Dynamic Voltage 
> Frequency Scaling in i915, whose rough proposal is provided below.
> Please go through the options and provide your feedback.
>
>
>
> What is DVFS ?
>
>                 Any SKU is capable of running at more than one display 
> CD clock value but is configured to a default value during boot and is 
> left untouched afterwards. Lowering this Display CD clock  will result 
> in better power savings while raising this will result in capability 
> to support larger resolution displays. So the best scenario is to 
> always detect the attached displays and adjust the CD Clock to the minimum required by the displays.
> DVFS is the process of dynamically changing the display CD clock based 
> on attached displays.
>
>
>
> Usecases: ( considers low resolution LFP is used with 4K HDMI panel)
>
> Ø  EDP (19x10) LFP panel alone is present at boot and can be driven 
> with lower CD clock, thus saving power.
>
> Ø  EDP (19x10) LFP panel was present at boot and 4K HDMI display is 
> hot plugged in to the system. CD clock can be increased to the 
> required value and then we can drive 4K panel. Thus save power while 
> only LFP is in use but also provide the ability to support 4K displays.
>
> Ø  4K HDMI display is unplugged from the system, CD clock can now be 
> lowered to the value required to drive LFP alone to save power.
>
> Ø  Boot with LFP and 4K HDMI connected, the CD clock will be 
> programmed to the value required to drive 4K HDMI.
>
>
>
> Technical Restrictions:
>
> Ø  DVFS can be performed only when all displays are turned off
> (pipe/port/plane,etc)
>
>
>
> Ux Restrictions:
>
> Ø  Flash/flicker should be avoided as much as possible( i.e during 
> unplug of HDMI avoid immediately lowering the CD clock after hotunplug 
> since it will result in flicker on LFP )
>
>
>
> Possible Solutions :
>
> Ø  Policy + implementation in driver
>
> o   Driver will set the cd clock during boot based on attached panels
>
> o   Post boot driver has to track each modeset for CD clock and resolution
> support.
>
> o   If any change in CD clock is needed, driver has to disable all displays
> , change the cd clock and enable back all displays
>
> o   Pros:
>
> ·         Changes are contained within driver
>
> o   Cons:
>
> ·         Complexity increases within driver
>
> ·         User land/ HWC will be blind to internal operations
>
> Ø  Policy in HWC and implementation in driver
>
> o   Driver will set the cd clock during boot based on attached panels
>
> o   Post boot, driver will fail any modeset that cannot be supported
>
> o   HWC will be responsible for disabling all displays, issuing IOCTL to
> change CD clock and enabling required displays
>
> o   Pros:
>
> ·         Driver implementation will be simple and clean
>
> ·         User land/HWC will be aware of operations and handle any special
> cases such as video playback
>
> o   Cons:
>
> ·         Solution requires HWC & Driver changes.
>
>
>
> Our recommendation is for HWC + Driver changes considering our primary 
> target of Android and the pros/cons mentioned there.
>
>
>
> Sorry for the long mail J, Please provide your feedback or questions 
> on this.
>
>
>
> regards,
>
> Sivakumar
>
>
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx