Re: [PATCH V4 22/30] thermal: exynos: Add support for exynos5440TMU sensor.

From: Eduardo Valentin
Date: Fri May 31 2013 - 11:29:24 EST

Amit and Jonghwa,

On 18-05-2013 01:23, jonghwa3.lee@xxxxxxxxxxx wrote:
> On 2013ë 05ì 14ì 18:58, Amit Daniel Kachhap wrote:
>
>> This patch modifies TMU controller to add changes needed to work with
>> exynos5440 platform. This sensor registers 3 instance of the tmu controller
>> with the thermal zone and hence reports 3 temperature output. This controller
>> supports upto five trip points. For critical threshold the driver uses the
>> core driver thermal framework for shutdown.
>>
>> Acked-by: Kukjin Kim <kgene.kim@xxxxxxxxxxx>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@xxxxxxxxxxx>
>> ---
>> .../devicetree/bindings/thermal/exynos-thermal.txt | 28 ++++++++++++-
>> drivers/thermal/samsung/exynos_tmu.c | 43 +++++++++++++++++--
>> drivers/thermal/samsung/exynos_tmu.h | 6 +++
>> drivers/thermal/samsung/exynos_tmu_data.h | 2 +
>> 4 files changed, 72 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index 535fd0e..970eeba 100644

<cut>

>> + goto out;
>
>
> I have a question about your implementation for supporting EXYNOS5440.
> I don't know exactly how EXYNO5440's tmu is working, but just guess it would be
> similar with other EXYNOS series's without number of thermal sensors. (exclusive
> register map and threshold level). Due to the multiple number of thermal sensor
> in EXYNOS5440, it have multiple thermal zone devices and that's why it just
> leave interrupt pin in pending if interrupt is not its, right?
>
> So, my curious is, why we make all platform devices for each of thermal zone
> devices? Why don't you just handle all thermal zone devices with one platform
> device?
>
> Yes, It's probably right to make multiple devices node to support them, because
> it has different physical hardware(sensors). But we have one TMU , don't we?
> (Maybe my assumption is wrong, I assume that it has one TMU because it looks
> like it has only one irq line.). If I'm right, I think it is better to manage
> all thermal zone devices with one platform device. Then, we don't need to leave
> irq handler with leaving it pendded like above and also we may not need other
> your patches like adding base_common iomem variable.
>
> I'd like to listen your opinion about this.
>


I understand the concern risen by Jonghwa. In fact, this is a bit
confusing. The way I have decided to design the driver for TI
(drivers/thermal/ti-soc-thermal under thermal tree next branch) is to
have one platform device for the bandgap IP (that would be probably
equivalent of your TMU).

Reasoning is to have a exact match between platform device and real HW
device interface. Thus its device resources are belonging to one single
device node. In TIs case, the resources, regarding IRQs, IO map area,
registers, etc, are belonging to the bandgap IP not to sensors. That
alone convinced me to use one single device node, instead of several,
per sensor. In fact, for OMAP devices it is a bit more complicated as
the bandgap is actually behind the control module, which holds the
interface. But that is another story.

So, in this case I decided to have 1 single platform device representing
the bandgap IP, which exposes and handles several thermal zones (one per
sensor). And of course, owns and manages all related resources (IRQ,
gpio and IO mem area).

To what I have understood of your case, I believe it is the very same
case, so I would recommend reusing the proposed design.

Keep in mind that this obviously does not stop you of having different
policies or trip setups per sensor. The framework is flexible in this sense.

I hope this helps.

> Thanks,
> Jonghwa
>
>> + }
>>
>> exynos_report_trigger(data->reg_conf);
>> mutex_lock(&data->lock);
>> @@ -358,7 +390,7 @@ static void exynos_tmu_work(struct work_struct *work)
>>
>> clk_disable(data->clk);
>> mutex_unlock(&data->lock);
>> -
>> +out:
>> enable_irq(data->irq);
>> }
>>
>> @@ -520,7 +552,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>> return ret;
>>
>> if (pdata->type == SOC_ARCH_EXYNOS ||
>> - pdata->type == SOC_ARCH_EXYNOS4210)
>> + pdata->type == SOC_ARCH_EXYNOS4210 ||
>> + pdata->type == SOC_ARCH_EXYNOS5440)
>> data->soc = pdata->type;
>> else {
>> ret = -EINVAL;
>> diff --git a/drivers/thermal/samsung/exynos_tmu.h b/drivers/thermal/samsung/exynos_tmu.h
>> index 65443d7..9151a30 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.h
>> +++ b/drivers/thermal/samsung/exynos_tmu.h
>> @@ -44,6 +44,7 @@ enum trigger_type {
>> enum soc_type {
>> SOC_ARCH_EXYNOS4210 = 1,
>> SOC_ARCH_EXYNOS,
>> + SOC_ARCH_EXYNOS5440,
>> };
>>
>> /**
>> @@ -132,6 +133,8 @@ enum soc_type {
>> * @emul_temp_shift: shift bits of emulation temperature.
>> * @emul_time_shift: shift bits of emulation time.
>> * @emul_time_mask: mask bits of emulation time.
>> + * @tmu_irqstatus: register to find which TMU generated interrupts.
>> + * @tmu_pmin: register to get/set the Pmin value.
>> */
>> struct exynos_tmu_registers {
>> u32 triminfo_data;
>> @@ -199,6 +202,9 @@ struct exynos_tmu_registers {
>> u32 emul_temp_shift;
>> u32 emul_time_shift;
>> u32 emul_time_mask;
>> +
>> + u32 tmu_irqstatus;
>> + u32 tmu_pmin;
>> };
>>
>> /**
>> diff --git a/drivers/thermal/samsung/exynos_tmu_data.h b/drivers/thermal/samsung/exynos_tmu_data.h
>> index 0e2244f..4acf070 100644
>> --- a/drivers/thermal/samsung/exynos_tmu_data.h
>> +++ b/drivers/thermal/samsung/exynos_tmu_data.h
>> @@ -91,6 +91,8 @@
>> #define EXYNOS_EMUL_DATA_MASK 0xFF
>> #define EXYNOS_EMUL_ENABLE 0x1
>>
>> +#define EXYNOS_MAX_TRIGGER_PER_REG 4
>> +
>> #if defined(CONFIG_CPU_EXYNOS4210)
>> extern struct exynos_tmu_platform_data const exynos4210_default_tmu_data;
>> #define EXYNOS4210_TMU_DRV_DATA (&exynos4210_default_tmu_data)
>
>
>
>


--
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin

Attachment: signature.asc
Description: OpenPGP digital signature