Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add OMAP4460 OPP definitions for voltage and frequencies based on
OMAP4460 ES1.0 DM Operating Condition Addendum Version 0.1
The following exceptions are present:
* Smartreflex support is still on experimental mode: the gains and min
limits are currently pending characterization data. Currently OMAP4430 values
are used.
* Efuse offset for core OPP100-OV setting is not clear in documentation.
* IVA OPPs beyond OPP100 are disabled due to the delta between max OMAP4460
current requirements and Phoenix Max supply on VCORE2 in the default
configuration - boards which have supply which can support this should
explicitly call opp_enable and enable the same.
* MPU OPPs > OPPTURBO can easily be detected using a efuse burnt - currently
disabled pending clock changes to support DCC feature.
[nm@ti.com: cleanups and updates from Datamanual]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
[t-kristo@ti.com: rebased to linux-3.6-rc5]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This is a first pass at reorganizing mach-omap2/voltage.c:
- Separate almost all of the data from the code of mach-omap2/voltage.c.
The code remains in mach-omap2/voltage.c. The data goes into one
of several places, depending on what type of data it is:
- Silicon process/validation data: mach-omap2/opp*_data.c
- VC (Voltage Controller) data: mach-omap2/vc*_data.c
- VP (Voltage Processor) data: mach-omap2/vp*_data.c
- Voltage domain data: mach-omap2/voltagedomains*_data.c
The ultimate goal is for all this data to be autogenerated, the same
way we autogenerate the rest of our data.
- Separate VC and VP common data from VDD-specific VC and VP data.
- Separate common voltage.c code from SoC-specific code; reuse common code.
- Reorganize structures to avoid unnecessary memory loss due to unpacked
fields.
There is much left to be done. VC code and VP code should be separated out
into vc*.c and vp*.c files. Many fields in the existing structures are
superfluous, and should be removed. Some code in voltage.c seems to be
duplicated; that code should be moved into functions of its own. Proper
voltage domain code should be created, as was done with the powerdomain
and clockdomains, and powerdomains should reference voltagedomains.
Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks
to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs
that prevented OMAP4 from booting:
https://patchwork.kernel.org/patch/587311/
His patch has been folded into this one to avoid breaking OMAP4
between patches. Thanks also to Kevin Hilman <khilman@ti.com> for
finding and fixing a compile problem when !CONFIG_PM:
http://www.spinics.net/lists/arm-kernel/msg118067.html
His patch has also been folded into this one to avoid breaking
!CONFIG_PM builds.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Shweta Gulati <shweta.gulati@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Add OPP data for OMAP34xx and OMAP36xx and initialization functions
to populate OPP tables based on current SoC.
introduce an OMAP generic opp initialization routine which OMAP3
and OMAP4+ SoCs can use to register their OPP definitions.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
