Add TMU support for Exynos5250 based SMDK5250

From: Akshay Saraswat <[email protected]>

Fdt entry for Exynos TMU driver specific pre-defined values used for calibration of current temperature and defining threshold values.

Signed-off-by Akshay Saraswat <[email protected]>

Acked-by Simon Glass <[email protected]>

arch/arm/dts/exynos5250.dtsi +0 -0

index fa4d498..db22db6 100644

arch/arm/dts/exynos5250.dtsi +1 -0

+       };
 };

board/samsung/dts/exynos5250-smdk5250.dts +13 -0

index b6fbb67..2d3ecca 100644
@@ -26,4 +26,17 @@
                        phy-mode = "mii";
                };
        };
+
+       tmu at 10060000 {
+               samsung,mux             = <6>;
+               samsung,min-temp        = <25>;
+               samsung,max-temp        = <125>;
+               samsung,start-warning   = <95>;
+               samsung,start-tripping  = <105>;
+               samsung,efuse-min-value = <40>;
+               samsung,efuse-value     = <55>;
+               samsung,efuse-max-value = <100>;
+               samsung,slope           = <268470274>;
+               samsung,dc-value        = <25>;
+       };
 };

doc/device-tree-bindings/exynos/tmu.txt new file +9 -0

new file mode 100644
index 0000000..99e7164
@@ -0,0 +1,35 @@
+Exynos Thermal management Unit
+
+The device node for TMU that is a part of Exynos5250
+SOC is as described in the document "Open Firmware Recommended
+Practic : Universal Serial Bus" with the following modifications
+and additions:
+
+Required properties :
+ - compatible : Should be "samsung,exynos-tmu" for TMU

doc/device-tree-bindings/exynos/tmu.txt new file +16 -0

+
+Example:
+
+tmu at 10060000 {
+       compatible = "samsung,exynos-tmu"
+       samsung,mux = <6>;
+       samsung,min-temp = <25>;
+       samsung,max-temp = <125>;
+       samsung,start-warning = <95>;
+       samsung,start-tripping = <105>;
+       samsung,efuse-min-value = <40>;
+       samsung,efuse-value = <55>;
+       samsung,efuse-max-value = <100>;
+       samsung,slope = <268470274>;
+       samsung,dc-value = <25>;
+};

include/fdtdec.h +1 -0

index da3c85f..2d74cec 100644
@@ -70,6 +70,7 @@ enum fdt_compat_id {
        COMPAT_NVIDIA_TEGRA20_DC,       /* Tegra 2 Display controller */
        COMPAT_SMSC_LAN9215,            /* SMSC 10/100 Ethernet LAN9215 */
        COMPAT_SAMSUNG_EXYNOS5_SROMC,   /* Exynos5 SROMC */
+       COMPAT_SAMSUNG_EXYNOS_TMU,      /* Exynos TMU */
 
        COMPAT_COUNT,
 };

lib/fdtdec.c +1 -1

index 85e733c..2b9df7f 100644
@@ -47,6 +47,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
        COMPAT(NVIDIA_TEGRA20_DC, "nvidia,tegra20-dc"),
        COMPAT(SMSC_LAN9215, "smsc,lan9215"),
        COMPAT(SAMSUNG_EXYNOS5_SROMC, "samsung,exynos-sromc"),
+       COMPAT(SAMSUNG_EXYNOS_TMU, "samsung,exynos-tmu"),
 };
 
 const char *fdtdec_get_compatible(enum fdt_compat_id id)
--

1.7.2.3

From: Akshay Saraswat <[email protected]>

Adding Exynos Thermal Management Unit driver to monitor SOC temperature and take actions corresponding to states of TMU. System will shutdown if tripping temperature is reached.

From: Akshay Saraswat <[email protected]>

Adding API in power for system shutdown when tripping value is reached in Exynos Thermal Management Unit.

Signed-off-by Akshay Saraswat <[email protected]>

Acked-by Simon Glass <[email protected]>

Dear Hatim Ali,

Quoted 5 lines · In message <[email protected]> you wrote:

From: Akshay Saraswat <[email protected]>

Adding API in power for system shutdown when tripping value is reached in Exynos Thermal Management Unit.

Quoted 2 lines

Signed-off-by Akshay Saraswat <[email protected]>

Acked-by Simon Glass <[email protected]>

If we add something like this, it should be general enough to be used by other systems as well, i. e. please chose a generic API like plain poweroff() or similar.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Chapter 1 -- The story so far:
In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 4 lines

If we add something like this, it should be general enough to be used by other systems as well, i. e. please chose a generic API like plain poweroff() or similar.

Maybe rename the function and move to a new include/power.h header, with the implementation staying where it is?

From: Akshay Saraswat <[email protected]>

Adding a generic polling function to continuously monitor events and trigger actions corresponding to them.

Signed-off-by Akshay Saraswat <[email protected]>

Acked-by Simon Glass <[email protected]>

README +0 -0

index 037513a..0e4083c 100644

Dear Hatim Ali,

Quoted 13 lines · In message <[email protected]> you wrote:

From: Akshay Saraswat <[email protected]>

Adding a generic polling function to continuously monitor events and trigger actions corresponding to them.

Signed-off-by Akshay Saraswat <[email protected]>

Acked-by Simon Glass <[email protected]>

README +0 -0

index 037513a..0e4083c 100644

README Configuration Settings: · line 2849

Quoted 9 lines

README +6 -0

@@ -2841,6 +2841,13 @@ Configuration Settings:
              the application (usually a Linux kernel) when it is
              booted
 
+- CONFIG_BOARD_POLL
+     There are various scenarios in which parallel-thread like
+     polling is required to monitor status of variety of devices.
+     For such situations CONFIG_BOARD_POLL shall be enabled
+     and funtion call board_poll_devices() from console_tstc()
+     will then poll for the device status as defined inside function.

Sorry, but I dislike this, for a number of reasons.

1) There is, and has always been, a very basic design decision, that U-Boot is strictly single-tasking, i. e. we don't have any kind of "background activities" goind on. Your introduction of a device polling mechanism violates this principle.

I don't say that this is unacceptable, but we have to be aware that this is a far-reaching decision, so we should consider it very carefully.

If anything like this gets implemented, it has to be done in a way that will be general enough to be useful to others as well.

2) U-Boot is a boot loader, not an OS. Do we really need continuous temperature management in U-Boot? I think not. After all, our main purpose is to boot an OS, and do that as fast as possible. The majority of users will see U-Boot running only for a few milliseconds, and only when they boot the device - which may be very seldom.

So what exactly do we need this for?

3) Your hooking of a device polling into console_tstc() is broken by
design. It may be sufficient for the specific use case you have
in mind here, but it is totally useless for any other purpose.

This needs a lot of additional thought, and major changes to the implementation.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Without facts, the decision cannot be made logically. You must rely on your human intuition.
-- Spock, "Assignment: Earth", stardate unknown
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 3 lines

If anything like this gets implemented, it has to be done in a way that will be general enough to be useful to others as well.

Yes. It isn't really clear how this sort of thing should be done, but creating a board polling function seems like a reasonable idea. It's then just a question of when to call it. Since there is no particular idle or event loop in U-Boot, perhaps we need to create one, and the console code is probably the only sensible place since it is waiting for user input.

I am not sure about the general issue. Obviously some sort of background activity is going on in the chip all the time, and monitoring is sometimes necessary. I am not sure about the best approach for this.

By monitoring temperature we can be sure that the system does not overheat - it does depend on the hardware of course (power output, heatsinks) but it can happen very quickly, certainly within a few 10s of seconds.

Quoted 2 lines

This needs a lot of additional thought, and major changes to the implementation.

Perhaps add a new idle function in common code which can be called from various places (including console), and itself calls board_poll_devices()? That is cosmetic, but does at least detach the code from the console.

Dear Simon Glass,

Quoted 10 lines · In message <CAPnjgZ3VedAoM9tkzHoHWPi9cAJ=6WQ4CDOb0zQMgi7XwGwWBQ@mail.gmail.com>…

Quoted 3 lines

If anything like this gets implemented, it has to be done in a way that will be general enough to be useful to others as well.

Yes. It isn't really clear how this sort of thing should be done, but creating a board polling function seems like a reasonable idea. It's then just a question of when to call it. Since there is no particular idle or event loop in U-Boot, perhaps we need to create one, and the console code is probably the only sensible place since it is waiting for user input.

No, using the console driver for such a hook is not sensible at all.

Do we really have to re-invent the wheel each time we need one?

If we need a periodic service, then this should be obviously (at least this seems obvious to me) be bound to the timer services. On PPC, we could for example simply hook it in the timer interrupt.

Also, this should not be considered as somethin board specific as the name "board polling function" might suggest. What is being discussed here is not more and not less than support for periodic, asynchronous services. So let's call it that, so everybody understand what it's about.

Quoted 5 lines

I am not sure about the general issue. Obviously some sort of background activity is going on in the chip all the time, and monitoring is sometimes necessary. I am not sure about the best approach for this.

I agree about the "sometimes necessary". In this specific case, I doubt is this is one of these "some" cases. But I asked this before.

Quoted 4 lines

By monitoring temperature we can be sure that the system does not overheat - it does depend on the hardware of course (power output, heatsinks) but it can happen very quickly, certainly within a few 10s of seconds.

Is this some theoretical consideration, or does it refer to the actual state of a specific piece of hardware?

Assume we have such a system - how would it be going to be used? Example:

- power on
- U-Boot enters (either directly or as a result of some boot error or similar) the interactive command line interface and waits for input from the user
- temperature monitoring detects overheating
- system powers down

How would one recover from that?

Would it not make much more sense to bring up the system in such a mode of operation that no overheating will happen?

Quoted 8 lines

Quoted 3 lines

This needs a lot of additional thought, and major changes to the implementation.

Perhaps add a new idle function in common code which can be called from various places (including console), and itself calls board_poll_devices()? That is cosmetic, but does at least detach the code from the console.

No. This is crap. If we need a periodic service, we should implement one, and not add hooks here and there at random. We already did this once (for the watchdog triggering), and look what a crap it is. We should not repeat this.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de I often quote myself; it adds spice to my conversation. - G. B. Shaw

Quoted 6 lines

Also, this should not be considered as somethin board specific as the name "board polling function" might suggest. What is being discussed here is not more and not less than support for periodic, asynchronous services. So let's call it that, so everybody understand what it's about.

Well that means interrupts. Are you suggesting that we implement generic timers and allow drivers to register a timer callback function to be called periodically? That seems like a bold move, but we could do it.

Quoted 1 line

How would one recover from that?

Firstly we can detect that the system is idle (by noticing that it has been long time since a keypress, for example), and reduce the CPU clock speed until we next see a key. This might be enough to remove the problem. Perhaps we should add some sort of feature to console to

record the time of last key input to facilitate that. There are lots of ways to do it.

Secondly, when the system warms up we can display a warning on the console, and perhaps reduce CPU speed further.

Thirdly, when the system starts to melt, we can power it off.

So it seems that some sort of timer hook might be good for the patch under discussion, but for the watchdog we need an idle loop or

similar. The timer hook does open a bit of a can of worms for other reasons - e.g. you are in the middle of an i2c transaction, the timer fires, you jump to the temperature monitor which wants to use i2c to find out the temperature. I thought we wanted to avoid this sort of thing in U-Boot so long as possible.

We could perhaps add an 'idle hook' so that callers can register themselves:

and then change all the WATCHDOG_RESET() calls to call idle_poll() instead.

We could perhaps have a flags parameter to permit selection of what sort of things to poll - e.g. IDLE_POLL_WATCHDOG for a quick watchdog reset, IDLE_POLL_ALL to call all the registered handlers).

The hooks could then be generalised to support timers, with the proviso that timers are only ever invoked from the idle loop so that

Any of the above is much more radical than this patch.

Dear Simon Glass,

Quoted 7 lines · In message <CAPnjgZ0bmsJAx4MAk-+GLo+QLC-6zbgp24N=BNqO=2fsUikjDw@mail.gmail.com>…

Quoted 6 lines

Also, this should not be considered as somethin board specific as the name "board polling function" might suggest. What is being discussed here is not more and not less than support for periodic, asynchronous services. So let's call it that, so everybody understand what it's about.

Quoted 4 lines

Well that means interrupts. Are you suggesting that we implement generic timers and allow drivers to register a timer callback function to be called periodically? That seems like a bold move, but we could do it.

Which architectures do not use interrupts for the timer services?

Quoted 7 lines

Quoted 2 lines

How would one recover from that?

Firstly we can detect that the system is idle (by noticing that it has been long time since a keypress, for example), and reduce the CPU clock speed until we next see a key. This might be enough to remove the problem. Perhaps we should add some sort of feature to console to

No, this is just a crappy design.

Assume you load some big image and write it to NAND (or you do other operations that take some time; eventually in a loop). Your keyboard dependet code would not trigger here, and you would just overheat the system.

I mean, what good is such protection when a simple "while : ; do : ; done" will just toast your box?

Quoted 3 lines

record the time of last key input to facilitate that. There are lots of ways to do it.

Sorry, but keyboard activity has _nothing_ to do ith it and is the totally wrong place to attach such functionality to.

Quoted 5 lines

Secondly, when the system warms up we can display a warning on the console, and perhaps reduce CPU speed further.

Thirdly, when the system starts to melt, we can power it off.

Would you ever buy such a design? I wouldn't. And any competing company would probably have excellent arguments for their own marketing material.

Quoted 3 lines

So it seems that some sort of timer hook might be good for the patch under discussion, but for the watchdog we need an idle loop or

I don;t understand your arguments here. You are aware that we don;t really have watchdog support in U-Boot (not in the sense that we monitor U-Boot's operation) - we only make sure to trigger it periodically.

Quoted 6 lines

similar. The timer hook does open a bit of a can of worms for other reasons - e.g. you are in the middle of an i2c transaction, the timer fires, you jump to the temperature monitor which wants to use i2c to find out the temperature. I thought we wanted to avoid this sort of thing in U-Boot so long as possible.

Yes, we definitely do want to avoid this, which is the reson why I insist on asking of we actually need such a feature in U-Boot. If the hardware cannot protect itself sufficiently and relies on software support, you are doomed anyway, because somebody will always just do some stupid things and find out that he detected a HCF macro...

Quoted 2 lines

We could perhaps add an 'idle hook' so that callers can register themselves:

Where exactly would you hook that to, if not to some timer interrupt?

ANd please tink about this again - if you talk about an 'idle hook', you actually are talking about an "idle task", i. e. about introducing a multi-task concept (even if it's just a simple one).

This is not exactly a small can of worms, and I guess these worms have a smell ...

Quoted 1 line

and then change all the WATCHDOG_RESET() calls to call idle_poll() instead.

Oh. Cooperative multitasking...

Are you really, really sure we want to do that?

Quoted 7 lines

We could perhaps have a flags parameter to permit selection of what sort of things to poll - e.g. IDLE_POLL_WATCHDOG for a quick watchdog reset, IDLE_POLL_ALL to call all the registered handlers).

The hooks could then be generalised to support timers, with the proviso that timers are only ever invoked from the idle loop so that

Yes, we can do all that. We can actually implement a full-blown OS.

Are you really, really sure we want to do that?

Quoted 2 lines

Any of the above is much more radical than this patch.

But the patch as submitted here is not even functional...

Best regards,

Wolfgang Denk

--

DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Weekends were made for programming. - Karl Lehenbauer

Quoted 3 lines

I mean, what good is such protection when a simple "while : ; do : ; done" will just toast your box?

Well it will force a hard power off - the hardware has a hard limit at which it will power off. Don't do that! The more common case is the user sitting at a prompt doing nothing, and that's the case which prompted this patch I think.

Quoted 2 lines

Sorry, but keyboard activity has _nothing_ to do ith it and is the totally wrong place to attach such functionality to.

Can you suggest an alternative place which gives us an indicator of user activity?

So long as it had some fail safe power off when things get hot it is ok. But we need to try to avoid getting into that condition. Running flat out at 1.7GHz waiting for keyboard input that may never come is not good design.

Actually I was happy enough with a simple patch to indicate idle in the console code :-)

<1> <2> <3> <4>
this patch idle support co-op multitasking full-blown OS

Please choose :/) I think you are saying that <1> is too much of a hack. Clearly <4> is not why we are here. I suggest <1>, or failing that, <2>. I think <3> is scary and I think there is clear daylight between <2> and <3>.

But if you can accept that this feature is useful, how would you implement it?

Quoted 1 line

But the patch as submitted here is not even functional...

It seems to work as intended, albeit I'm sure there are flaws.

From: Alim Akhtar <[email protected]>

Adds a new u-boot command to read current temprature from tmu driver.

Signed-off-by Alim Akhtar <[email protected]>

Acked-by Simon Glass <[email protected]>

Dear Hatim Ali,

Quoted 6 lines · In message <[email protected]> you wrote:

From: Alim Akhtar <[email protected]>

Adds a new u-boot command to read current temprature from tmu driver.

Signed-off-by Alim Akhtar <[email protected]>

Acked-by Simon Glass <[email protected]>

Do we really need a new command here?

We already have dtt, which basicly does the same.

It makes no sense to add new commands for each new device, all doing basicly trhe same, just in an incompatible way.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The explanation requiring the fewest assumptions is the most likely
to be correct. -- William of Occam
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 5 lines

Do we really need a new command here?

We already have dtt, which basicly does the same.

Quoted 2 lines

It makes no sense to add new commands for each new device, all doing basicly trhe same, just in an incompatible way.

This patch feature does not use i2c as the temperature measurement is inside the SOC. I wonder whether cmd_dtt.c could be extended so that it only does the i2c stuff if CONFIG_SYS_DTT_BUS_NUM is defined. Then you could use dtt_get_temp() to get the termperature as now.