TI thermal framework: register cpufreq cooling device in module init

TI thermal framework: register cpufreq cooling device in module init

the CPUfreq cooling device is being registered in the wrong place.
We don't want to register a cooling device every time a CPU is
initialized. This is fundamentally wrong. Thus, this patch moves
the cooling device registration to module init instead.

Change-Id: I7886eb14c68e1bf696ef77e86326a62ea05b8c8b
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Willi Ye <williye97@gmail.com>

Conflicts:
	arch/arm/mach-omap2/omap2plus-cpufreq.c

Conflicts:
	arch/arm/mach-omap2/omap2plus-cpufreq.c
ARM:OMAP4:Thermal Framework:added TMP102 temperature sensor

ARM:OMAP4:Thermal Framework:added TMP102 temperature sensor

This patch adds kernel driver for TMP102 temperature sensor
TMP102 is controled through I2C bus.

Change-Id: I4012a0ab53945ad8a240f395bb321cf09ebeb3ea
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
TI thermal framework: fix initialization sequence and introduce "pcb" domain

TI thermal framework: fix initialization sequence and introduce "pcb" domain

This patch creates a new thermal domain, named "pcb". Also it teaches
the omap die governor how to be aware of a separated domain.

The pcb sensor will not be part of the "cpu" domain, but instead, it
is now part of the "pcb" domain. This will change the system so that,
instead of wrongly attempt to register two sensors on the same domain,
they will be registered on two different domains, but the governor
is aware of both domains.

By doing so, it is not necessary to keep track of sensors being
registered on the same domain, and deciding by looking up the
sensor names.

Now that governors can fetch the temperature from a different domain,
there is no need to keep feeding the framework with temperature reports
by means of running workqueues. This workaround was necessary
because there was an initialization issue while registering several
sensors in the same domain.

Now, because there are multiple domains, there is no need to keep
track on sensors being registered and their reports. For now,
these workqueues are not needed.

Change-Id: I6e2764fc1d49fbe97953c2a9a5192f8585c91aab
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
TI thermal framework: introduce the thermal framework debug capability

TI thermal framework: introduce the thermal framework debug capability

This is a initial implementation of the TI thermal framework debug entries.

As of now, the structure is like this:
<debugfs_dir>
  |- thermal_debug
      |- domains
          |- <domain_name file 0>
          .
          .
          .
          |- <domain_name file n>
      |- devices
          |- device_name 0
          |    |- <device_name 0 own entries>
          .
          .
          .
          |- device_name n
          |    |- <device_name 0 own entries>

Each domain_name file contains a report of the its corresponding domain, e.g.:

 # cat /sys/kernel/debug/thermal_debug/cpu
Domain name: cpu
Temperature sensor:
     Name: omap_ondie_sensor
     Current temperature: 62400
Governor:
     Name: omap_ondie_governor
Cooling agents:
     Name: cpufreq_cooling

Each thermal device participating in a specific thermal domain
will have the opportunity to report their own specific debug
entries on this debug file for that domain. This is achieved
by means of the new thermal device ops callback .debug_report
which receives the target seq file.

Besides, each device registered in this framework will also
have the opportunity to create its own debug entries (directories
or files) under a directory with its name under the "devices"
directory. This is achieved by means of the .register_debug_entries
callback function.

Because we have now a debugfs dependency, this framework is
now initialized by means of the fs_initcall. This way
it will be ready before any registration of thermal devices.

Change-Id: I8b2d861a9263baa2d8af9c6a5edf07a8cfb88388
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
TI TFW: omap die governor:fix for staying in PANIC zone

TI TFW: omap die governor:fix for staying in PANIC zone

the OMAP4470 more heats up. The patch adds timer which
helps to avoid staying in PANIC zone too long time.

patch realises following algorithm

1. panic_zone_reached == 1;
2. schedule work to be executed after 2s;
3. scheduled work will cancelled if zone will be changed through 2s;
4. after 2s executes scheduled work
5. panic_zone_reached == 2;
6. schedule work to be executed after 4s relative to point 1
7. etc

Change-Id: Ide8bd588b0bf504e2378b5a655fefdeee51c90b1
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
OMAP4 CPU Thermal governor:removes repetitive info

OMAP4 CPU Thermal governor:removes repetitive info

The thermal governor prints info after each crossing of a thermal treshold.
Often treshold is crossed but thermal zone was not changed. The printed info
to clogs a console and dosen't give an effective information. The patch
removes repetitive info for all zone except for the panic zone. The
panic zone is critical and a duplicate info must be.

Change-Id: I278a938b615296264446fe7d5b209021ec0121c0
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
TI thermal framework: rework initialization sequence

TI thermal framework: rework initialization sequence

The duty cooling device is being registered in the
wrong place. We don't want to register a cooling device
every time a CPU is initialized.  Thus, this patch moves
the cooling device registration to module init instead.

Change-Id: Ib3cf55e8dde719c5736b201d9682ff515d2b1399
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Willi Ye <williye97@gmail.com>

Conflicts:
	arch/arm/mach-omap2/omap2plus-cpufreq.c

Conflicts:
	arch/arm/mach-omap2/omap2plus-cpufreq.c