21 Oct, 2013

2 commits


15 Oct, 2013

4 commits

  • This patch changes the behavior of TI SoC thermal driver
    when there is a PCB thermal zone.

    Instead of reporting an error code when reading from
    PCB temperature sensor fails, this patch will make
    the driver attempt to compose the hotspot extrapolation
    based on bandgap readings only.

    Cc: Zhang Rui
    Cc: linux-pm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Eduardo Valentin

    Eduardo Valentin
     
  • The commit d0a0ce3e77c795258d47f9163e92d5031d0c5221 ("thermal: exynos: Add
    missing definations and code cleanup") has removed setting of test MUX address
    value at TMU configuration setting.

    This field is not present on Exynos4210 and Exynos5 SoCs. However on Exynos4412
    SoC it is required to set this field after reset because without it TMU shows
    maximal available temperature, which causes immediate platform shutdown.

    Signed-off-by: Lukasz Majewski
    Reviewed-by: Bartlomiej Zolnierkiewicz
    Reviewed-by: Tomasz Figa
    Signed-off-by: Eduardo Valentin

    Lukasz Majewski
     
  • Up till now Exynos5250 and Exynos4412 had the same definitions for TMU
    data. Following commit changes that, by introducing separate
    exynos4412_default_tmu_data structure.

    Since Exynos4412 was chronologically first, the corresponding name for
    TMU registers and default data was renamed.

    Additionally, new SOC_ARCH_EXYNOS4412 type has been defined.

    Moreover, the SOC_ARCH_EXYNOS name has been changed to SOC_ARCH_EXYNOS5250.

    Signed-off-by: Lukasz Majewski
    Reviewed-by: Bartlomiej Zolnierkiewicz
    Reviewed-by: Tomasz Figa
    Signed-off-by: Eduardo Valentin

    Lukasz Majewski
     
  • The commit 4de0bdaa9677d11406c9becb70c60887c957e1f0
    ("thermal: exynos: Add support for instance based register/unregister")
    broke check for presence of therm_dev at global thermal zone in
    exynos_report_trigger().

    The resulting wrong test prevents thermal_zone_device_update() call, which
    calls handlers for situation when trip points are passed.
    Such behavior prevents thermal driver from proper reaction (when TMU interrupt
    is raised) in a situation when overheating is detected at TMU hardware.

    It turns out, that after exynos thermal subsystem redesign (at v3.12) this
    check is not needed, since it is not possible to register thermal zone
    without valid thermal device.

    Signed-off-by: Lukasz Majewski
    Reviewed-by: Bartlomiej Zolnierkiewicz
    Reviewed-by: Tomasz Figa
    Signed-off-by: Eduardo Valentin

    Lukasz Majewski
     

25 Sep, 2013

1 commit

  • x86_pkg_temp receives thermal notifications via a callback from a
    therm_throt driver, where thermal interrupts are processed.
    This callback is pkg_temp_thermal_platform_thermal_notify. Here to
    avoid multiple interrupts from cores in a package, we disable the
    source and also set a variable to avoid scheduling delayed work function.
    This variable is protected via spin_lock_irqsave. On one buggy platform,
    we still receiving interrupts even if the source is disabled. This
    can cause deadlock/lockdep warning, when interrupt is generated while under
    spinlock in work function.
    Change spin_lock to spin_lock_irqsave and spin_unlock to
    spin_unlock_irqrestore as the data it is trying to protect can also
    be modified in a notification call called from interrupt handler.

    Signed-off-by: Srinivas Pandruvada
    Signed-off-by: Zhang Rui

    Srinivas Pandruvada
     

03 Sep, 2013

5 commits

  • This patch avoids NULL pointer accesses while unregistering
    cpu cooling devices, in case a NULL pointer is received.

    Cc: Zhang Rui
    Cc: linux-pm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Eduardo Valentin

    Eduardo Valentin
     
  • When registering a thermal zone device using platform information
    via bind_params, the thermal framework will always perform the
    cdev binding using the lowest and highest limits (THERMAL_NO_LIMIT).

    This patch changes the data structures so that it is possible
    to inform what are the desired limits for each trip point
    inside a bind_param. The way the binding is performed is also
    changed so that it uses the new data structure.

    Cc: Zhang Rui
    Cc: linux-pm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Eduardo Valentin

    Eduardo Valentin
     
  • When registering a new thermal_device, the thermal framework
    will always add a hwmon sysfs interface.

    This patch adds a flag to make this behavior optional. Now
    when registering a new thermal device, the caller can
    optionally inform if hwmon interface is desirable. This can
    be done by means of passing a thermal_zone_params.no_hwmon == true.

    In order to keep same behavior as of today, all current
    calls will by default create the hwmon interface.

    Cc: David Woodhouse
    Cc: linux-acpi@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-pm@vger.kernel.org
    Cc: Zhang Rui
    Suggested-by: Wei Ni
    Signed-off-by: Eduardo Valentin

    Eduardo Valentin
     
  • When creating virtual hwmon devices based out of thermal
    zone devices, the virtual devices won't have parents.

    This patch changes the code so that the parent of virtual
    hwmon devices is the thermal zone device that they are
    based of.

    Cc: Zhang Rui
    Cc: linux-pm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Eduardo Valentin

    Eduardo Valentin
     
  • In order to improve code organization, this patch
    moves the hwmon sysfs support to a file named
    thermal_hwmon. This helps to add extra support
    for hwmon without scrambling the code.

    In order to do this move, the hwmon list head is now
    using its own locking. Before, the list used
    the global thermal locking. Also, some minor changes
    in the code were required, as recommended by checkpatch.pl.

    Cc: Zhang Rui
    Cc: linux-pm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Acked-by: Durgadoss R
    Signed-off-by: Eduardo Valentin

    Eduardo Valentin
     

29 Aug, 2013

6 commits


15 Aug, 2013

8 commits

  • Zhang Rui
     
  • In case the trend is not changing or when there is no
    request for throttling, it is expected that the instance
    would not change its requested target. This patch improves
    the code implementation to cover for this expected behavior.

    With current implementation, the instance will always
    reset to cdev.cur_state, even in not expected cases,
    like those mentioned above.

    This patch changes the step_wise governor implementation
    of get_target so that we accomplish:
    (a) - default value will be current instance->target, so
    we do not change the thermal instance target unnecessarily.
    (b) - the code now it is clear about what is the intention.
    There is a clear statement of what are the expected outcomes
    (c) - removal of hardcoded constants, now it is put in use
    the THERMAL_NO_TARGET macro.
    (d) - variable names are also improved so that reader can
    clearly understand the difference between instance cur target,
    next target and cdev cur_state.

    Cc: Zhang Rui
    Cc: Durgadoss R
    Cc: linux-pm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Reported-by: Ruslan Ruslichenko
    Signed-of-by: Eduardo Valentin
    Signed-off-by: Zhang Rui

    Eduardo Valentin
     
  • The cooling device only needs update on a new target state. Since we
    already check old target in thermal_zone_trip_update(), we can do one
    more check to see if it's a new target state. If not, we can reasonably
    save some uncecesary code execution.

    Signed-off-by: Shawn Guo
    Acked-by: Eduardo Valentin
    Signed-off-by: Zhang Rui

    Shawn Guo
     
  • Zhang Rui
     
  • …req_thermal_notifier()

    cpufreq_thermal_notifier() is to change the cpu's cpufreq in the allowed_cpus mask
    when associated thermal-cpufreq cdev's cooling state is changed. It's a cpufreq policy
    notifier handler and it will be triggered even if those cpus out of allowed_cpus has
    changed freq policy.

    cpufreq_thermal_notifier() checks the policy->cpu. If it belongs to allowed_cpus,
    change max_freq(default to 0) to the desire cpufreq value and pass 0 and max_freq
    to cpufreq_verify_within_limits() as cpufreq scope. But if not, do nothing and
    max_freq will remain 0. This will cause the cpufreq scope to become 0~0. This
    is not right. This patch is to return directly after finding cpu not belonging
    to allowed_cpus.

    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>

    Lan Tianyu
     
  • The error check is checking for a "base" mapped memory base
    instead of "base_common". Fixing the same.

    Signed-off-by: Naveen Krishna Chatradhi
    Signed-off-by: Zhang Rui

    Naveen Krishna Chatradhi
     
  • Enable automatic measurements at 10 Hz and use the alarm interrupt to react
    more quickly to sudden temperature changes above the passive or critical
    temperature trip points.

    Signed-off-by: Philipp Zabel
    Acked-by: Shawn Guo
    Signed-off-by: Zhang Rui

    Philipp Zabel
     
  • Set passive and critical trip point values depending on the maximum die
    temperature stored in the OCOTP fuses. This allows higher trip points
    for industrial and automotive rated i.MX6 SoCs.
    Also allow to configure the passive trip point from userspace.

    Signed-off-by: Philipp Zabel
    Acked-by: Shawn Guo
    Signed-off-by: Zhang Rui

    Philipp Zabel
     

13 Aug, 2013

14 commits