Ian Lepore 0140748043 Rework the cpu frequency management code for imx6. ... This adds the concept of "operating points," combinations of frequency and voltage at which the cpu is known to work correctly. Some day these should come from FDT data, but for now the table is hard-coded. This also allows tuning the min and max operating frequencies. The min frequency is what the thermal management code will slow down to if the core temperature gets too high. The max frequency is what gets used if the temperature is okay. Normally the max cannot be set higher than the value burned into the ocotp fuses as the chip's rated max, but there is now a new sysctl+tunable cpu_overclock_enable; when set to non-zero it allows raising the frequency above the ocotp value: USE WITH CARE! (At least one of my imx6 boards has a cpu whose ocotp values never got set correctly; they claim a max of 792mhz, but the physical markings on the chip say it's good to 1ghz.) Because all these values affect the entire SoC, there is a new sysctl node, hw.imx6, where all these values live. The values that are currently under dev.imx6_anatop.0 should probably move to hw.imx6 too, because "anatop" doesn't even mean anything to me, let alone to an end user.		2014-04-02 21:34:48 +00:00
..
imx	Rework the cpu frequency management code for imx6.	2014-04-02 21:34:48 +00:00
vybrid	Eliminate irq_dispatch.S. Move the data items it contained into arm/intr.c	2014-03-10 18:10:09 +00:00
fsl_ocotp.c	Oops, remove some dregs of debugging.	2014-02-16 03:30:22 +00:00
fsl_ocotpreg.h	Make it possible to access the ocotp registers before the ocotp device	2014-02-16 03:09:39 +00:00
fsl_ocotpvar.h	It turns out Freescale cleverly made the ocotp device compatible across	2014-02-15 21:21:57 +00:00