DRIVERS: MISC: change the DC cpufreq control to TF control

Duty cycle uses sys fs to control cpufreq. It is not safe.
The user(overclocker) can burn the device using simple script that
changes max_frequency. The thermal framework has own mechanism for
this and the patch changes the duty cycle mechanism to thermal
framework variant of cpufreq control.

Change-Id: Ifc0f8b81addb7524eb67d116e4780978739a67f3
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
modified for TUNA board by faux123

Signed-off-by: Willi Ye <williye97@gmail.com>

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

Conflicts:
	arch/arm/mach-omap2/omap2plus-cpufreq.c
board/omap2plus: fix duty cycle cooling coding error
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>

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
Staging Thermal FW: PCB Temp Sensor: Fix management of ADC conversion

Staging Thermal FW: PCB Temp Sensor: Fix management of ADC conversion

When an NTC thermistor is connected to the TWL6030 GPADC Channel #4,
twl6030_gpadc_conversion() function (from twl6030-gpadc driver) is
invoked.
This function stores different results into twl6030_gpadc_request
structure.
The PCB temp sensor driver shall use the ADC code instead of the
converted voltage value.
Later, the PCB temp sensor convert the ADC code into temperature
through a dedicated lookup table.

Change-Id: I1582e96035797f8c0dd6e529c65160a71e54cd6a
Signed-off-by: Sebastien Sabatier <s-sabatier1@ti.com>
ARM:OMAP4:Temp sensor: fix low limit for thresholds

ARM:OMAP4:Temp sensor: fix low limit for thresholds

As the full temperature range is -40 DegC to 125 Deg C,
this patch ensures that thresholds are higher than the low
limit (-40 Deg C) instead of 0 Deg C.

Change-Id: I28c49cd53703f9d9ed61458bc61612f4dbb476bb
Signed-off-by: Sebastien Sabatier <s-sabatier1@ti.com>
ARM:OMAP4:Temp Sensor: Define TALERT_IRQ as High level interrupt sensitive

ARM:OMAP4:Temp Sensor: Define TALERT_IRQ as High level interrupt sensitive

The thermal alert IRQ is registered as a threaded IRQ with TRIGGER_RISING and
ONESHOT flags.
This means that omap_talert_irq_handler() IRQ handler will be called upon a
rising edge of the T_ALERT (HW signal coming from HW comparison of current
temperature with hot & cold thresholds).
This means also that the irq line is disabled until the threaded handler has
been run (due to ONESHOT flag): the T_ALERT IRQ is masked at GIC level during
the threaded handler execution.
Any new thermal event occurring during the execution of the threaded handler
will not be detected. This may occur if OMAP on-die temperature variations are
fast and if the T_ALERT IRQ handler is delayed by higher priority interrupts.
Finally, the thermal governor is not informed of the new event and could
maintain incorrect constraints on CPU frequency for example.

This patch defines the TALERT_IRQ as TRIGGER_HIGH interrupt instead of
TRIGGER_RISING interrupt. Even if interrupt line is disabled during the handler
execution, HW will maintain the T_ALERT signal to high level if a second thermal
event occurs. When re-enabling the interrupt line, the omap_talert_irq_handler()
IRQ handler will be called again if needed.

Change-Id: I629d5a66702fb60b5f96773c717a2d87238dff2c
Signed-off-by: Sebastien Sabatier <s-sabatier1@ti.com>
Staging: add TI OMAP Thermal Framework drivers

backported for TUNA board by faux123

Conflicts:
	drivers/staging/Kconfig
	drivers/staging/Makefile

Conflicts:
	drivers/staging/Kconfig
	drivers/staging/Makefile
plat-omap: add compatibility with new TI OMAP thermal framework drivers
thermal framework: increase duty cycle throttle temperature from 65 to 75
omap4: add 4430 ES2.3 support

omap4: add 4430 ES2.3 support

And default to 4430 ES2.3 for unidentified silicon.

Change-Id: I06b0aa9c5f33af25345996cf9d0c994491093096
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
OMAP4: ID: Chip detection for OMAP4470

Add support for detection of the next chip in the OMAP4 family: OMAP4470 ES1.0

Change-Id: I931d3df6e69fdc3ee4a307c204a68fc9b3ff519b
Signed-off-by: Leonid Iziumtsev <x0153368@ti.com>
modified by faux123
OMAP4: Add 4430 ES2.3 chip is check

OMAP4: Add 4430 ES2.3 chip is check

4430 ES2.3 chip is check was missed during the merge
phase.

Putting it back in

Change-Id: I94fa2b8f803acb2a13c2f7db4558b2864106d213
Signed-off-by: Dan Murphy <dmurphy@ti.com>
ARM: OMAP2+: voltage: add check for missing PMIC info in VP init

If PMIC info is not available in omap_vp_init(), abort.

Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
[khilman: minor subject edits]
Signed-off-by: Kevin Hilman <khilman@ti.com>
ARM: OMAP: voltage: cleanup VC/VP error messages

Cleanup formatting/spacing on a  couple multi-line error messages.

Signed-off-by: Kevin Hilman <khilman@ti.com>