[RFC,0/6] Clock and power gating support

Message

Damien Hedde July 27, 2018, 2:37 p.m. UTC

This set of patches add support for power and clock gating in device objects.
It adds two booleans to the state, one for power state and one of clock state.

The state is controlled trough 2 functions, one for power and one for clock.
Two new methods *power_update* and *clock_update* is added to the device class
which are called on state change and can be overriden.

Default behavior is the following:
+ Device are initialized in powered and clocked state.
+ reset method is called when powering-up.

This set also implements this support in the cadence_uart device in the
xilinx_zynq platform as an example.

The 1st patch add the gating support to the base device object. The 2nd patch
add functions to act on a whole bus tree. The 3rd patch overrides the 
*power/clock_update* methods for sysbus devices to enable/disable the memory
regions according to the state.

The 4th patch updates the cadence_uart device and the 5th patch adds
uart clock gating support to the zynq clock controller *slcr*. The 6th patch
finally adds the support to *xilinx-zynq* machine.

This is an RFC as it remains open questions about the strategy to implement
this kind of support. Here's some remarks:

+ This set adds power and clock, some reset state could be added too. Although
  default behavior is tricky to implement because there is many kind of reset
  (eg syncronous/asynchronous).
+ I used methods which require to store links of controlled devices in
  clock/power controller. Using gpios or specifics child objects to
  achieve the same functionnaly is possible.
+ Power and clock state could be merged to a single 3-state (powered-off,
  unclocked, on) since clock does not really matters when powered-off.
+ Regarding migration, it's problematic to add the VMStateDescription in qdev
  so we let it to the specialization (eg in cadence_uart) to handle it. Is
  this a problem ? Anyway support of clock gating requires modification in
  specialization. It may not be necessary to store the gating states in each
  device, since it is stored already in the controller registers. But we would
  then have to set the gating state of devices in the controller's post_load
  which may occurs before or after devices VMState load: It seems tricky to
  ensure device state is correct at the end if gating update do side-effects.
+ theses patches add a simple vision (1 power, 1 clock). Devices can be more
  complex. For example, the zynq's uart has 2 independant clock domains:
  1 for the bus interface, 1 for uart operations. I'm not sure if we should
  keep 1, add the bus/device separation or do something more configurable on
  a per-specialization basis.

Feel free to comment,

Damien Hedde (6):
  qdev: add a power and clock gating support
  qdev: add power/clock gating control on bus tree
  sysbus: Specialize gating_update to enable/disable memory regions
  cadence_uart: add clock/power gating support
  zynq_slcr: add uart clock gating and soft reset support
  xilinx_zynq: add uart clock gating support

 include/hw/qdev-core.h |  50 ++++++++++++++++++++
 include/hw/sysbus.h    |   3 ++
 hw/arm/xilinx_zynq.c   |  20 +++++---
 hw/char/cadence_uart.c |  25 +++++++++-
 hw/core/qdev.c         | 103 +++++++++++++++++++++++++++++++++++++++++
 hw/core/sysbus.c       |  39 ++++++++++++++++
 hw/misc/zynq_slcr.c    |  63 +++++++++++++++++++++++++
 7 files changed, 296 insertions(+), 7 deletions(-)

Comments

Peter Maydell July 27, 2018, 2:59 p.m. UTC | #1

On 27 July 2018 at 15:37, Damien Hedde <[e-mail]> wrote:
> This set of patches add support for power and clock gating in device objects.
> It adds two booleans to the state, one for power state and one of clock state.
>
> The state is controlled trough 2 functions, one for power and one for clock.
> Two new methods *power_update* and *clock_update* is added to the device class
> which are called on state change and can be overriden.

So, you folks at Greensocs had a series a couple of years ago to try
to add clocktree support (which included handling things like guests
configuring clock rates, some clocks being "downstream" of others, and
so on). It didn't make it into mainline, though it did get a fair amount
of design/code review. How does this approach fit into / compare with
that ?

thanks
-- PMM

KONRAD Frederic July 27, 2018, 3:12 p.m. UTC | #2

Le 07/27/2018 à 04:59 PM, Peter Maydell a écrit :
> On 27 July 2018 at 15:37, Damien Hedde <[e-mail]> wrote:
>> This set of patches add support for power and clock gating in device objects.
>> It adds two booleans to the state, one for power state and one of clock state.
>>
>> The state is controlled trough 2 functions, one for power and one for clock.
>> Two new methods *power_update* and *clock_update* is added to the device class
>> which are called on state change and can be overriden.
> 
> So, you folks at Greensocs had a series a couple of years ago to try
> to add clocktree support (which included handling things like guests
> configuring clock rates, some clocks being "downstream" of others, and
> so on). It didn't make it into mainline, though it did get a fair amount
> of design/code review. How does this approach fit into / compare with
> that ?
> 
> thanks
> -- PMM
> 

Hi all,

I didn't have time to push a new version of the clock series and
I lost the track a little bit (was 13 months ago). Sorry for
that :(.. Would be still nice to have I think.

Cheers,
Fred

Mark Burton July 30, 2018, 1:17 p.m. UTC | #3

Hi Pete, sorry for the tardy reply, Im not in the office.


Your right  we shoujd have co-ordinated better the 2 patches, sorry for that.

Regarding this new patchset, we think there is a degree of complementary to the
clocktree one.
Here we simply add a couple of generic power states to a device. We
introduce
an interface to control power and clock gating on any devices, with sensible
generic behaviour (reset on power on, disabling memory regions when
asleep or
off). The device can specialize this to adopt specific behaviours.

It allows easy implementation of commonly found "system controller", "pin
controllers", "power management unit", or similar blocks in SoCs.
Specialization of devices can be implemented as-needed when a machine
requires
it.


Cheers
Mark

On 27 July 2018 17:22:30 KONRAD Frederic <[e-mail]> wrote:

> Le 07/27/2018 à 04:59 PM, Peter Maydell a écrit :
>> On 27 July 2018 at 15:37, Damien Hedde <[e-mail]> wrote:
>>> This set of patches add support for power and clock gating in device objects.
>>> It adds two booleans to the state, one for power state and one of clock state.
>>>
>>> The state is controlled trough 2 functions, one for power and one for clock.
>>> Two new methods *power_update* and *clock_update* is added to the device class
>>> which are called on state change and can be overriden.
>>
>> So, you folks at Greensocs had a series a couple of years ago to try
>> to add clocktree support (which included handling things like guests
>> configuring clock rates, some clocks being "downstream" of others, and
>> so on). It didn't make it into mainline, though it did get a fair amount
>> of design/code review. How does this approach fit into / compare with
>> that ?
>>
>> thanks
>> -- PMM
>
> Hi all,
>
> I didn't have time to push a new version of the clock series and
> I lost the track a little bit (was 13 months ago). Sorry for
> that :(.. Would be still nice to have I think.
>
> Cheers,
> Fred