ENGR00240988: gpu: fix deprecated idr calls on 3.10 kernel
The idr calls idr_pre_get() and idr_get_new_above() are deprecated on
3.10 kernel and cause the following build issues. Replace the calls
with the new idr_alloc() to fix the issue.
CC drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.o
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c: In function ‘_AllocateIntegerId’:
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c:776:5: error: ‘idr_pre_get’ is deprecated (declared at include/linux/idr.h:151) [-Werror=deprecated-declarations]
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c:784:5: error: ‘idr_get_new_above’ is deprecated (declared at include/linux/idr.h:166) [-Werror=deprecated-declarations]
ENGR00240988: gpu: allocate contiguous memory from CMA for 3.10 kernel
The Contiguous Memory Allocator (CMA) is mature in 3.10 kernel. Let's
change gpu driver to allocate contiguous memory from CMA pool. Doing so
will save not only the memblock reserve calls in machine code but also
the request_mem_region() and ioremap() in gpu driver. And all the
system memory will be seen by kernel no matter whether gpu driver is
running or not.
It also changes the default contiguousSize to 128 MiB for Freescale
adjustment.
ENGR00240988: gpu: __devinit and __devexit are unavailable on 3.10 kernel
__devinit, __devexit and __devexit_p are unavailable on 3.10 kernel.
Remove them for 3.10 to fix the compile issues below.
CC drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_driver.o
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_driver.c:1033:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘gpu_probe’
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_driver.c:1116:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘gpu_remove’
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_driver.c:1292:19: error: ‘gpu_probe’ undeclared here (not in a function)
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_driver.c:1293:5: error: implicit declaration of function ‘__devexit_p’ [-Werror=implicit-function-declaration]
ENGR00240988: gpu: comment out busfreq calls for 3.10 kernel
The busfreq driver is not ready yet on 3.10 kernel. Let's comment out
the busfreq header inclusion and function calls for now, and revisit it
later when busfreq driver is ready.
ENGR00240988: gpu: mach/hardware.h is not available in kernel 3.10
In kernel 3.10, drivers can not include any <mach/*> headers. Do not
include <mach/hardware.h> for 3.10 kernel to fix the follow build
errors.
CC drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_device.o
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_device.c:28:27: fatal error: mach/hardware.h: No such file or directory
CC drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.o
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c:33:27: fatal error: mach/hardware.h: No such file or directory
ENGR00273073-3 ARM: imx_v6_v7_defconfig: run save defconfig
Run make ARCH=arm savedefconfig on imx_v6_v7_defconfig to
clean up some unnecessary/unrelated items, so that next
time when we run savedefconfig, we only see related changes.
No functional changes.
ENGR00273073-2 cpufreq: add interactive governor for cpufreq
cpufreq: interactive: New 'interactive' governor
This governor is designed for latency-sensitive workloads, such as
interactive user interfaces. The interactive governor aims to be
significantly more responsive to ramp CPU quickly up when CPU-intensive
activity begins.
Existing governors sample CPU load at a particular rate, typically
every X ms. This can lead to under-powering UI threads for the period of
time during which the user begins interacting with a previously-idle system
until the next sample period happens.
The 'interactive' governor uses a different approach. Instead of sampling
the CPU at a specified rate, the governor will check whether to scale the
CPU frequency up soon after coming out of idle. When the CPU comes out of
idle, a timer is configured to fire within 1-2 ticks. If the CPU is very
busy from exiting idle to when the timer fires then we assume the CPU is
underpowered and ramp to MAX speed.
If the CPU was not sufficiently busy to immediately ramp to MAX speed, then
the governor evaluates the CPU load since the last speed adjustment,
choosing the highest value between that longer-term load or the short-term
load since idle exit to determine the CPU speed to ramp to.
A realtime thread is used for scaling up, giving the remaining tasks the
CPU performance benefit, unlike existing governors which are more likely to
schedule rampup work to occur after your performance starved tasks have
completed.
The tuneables for this governor are:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_time:
The minimum amount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic CPU load data to determine the appropriate workload.
/sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load
The CPU load at which to ramp to max speed.
Signed-off-by: Mike Chan <mike at android.com> Signed-off-by: Todd Poynor <toddpoynor at google.com> Signed-off-by: Allen Martin <amartin at nvidia.com> (submitted improvements) Signed-off-by: Axel Haslam <axelhaslam at ti.com> (submitted improvements) Signed-off-by: Anton Vorontsov <anton.vorontsov at linaro.org> Signed-off-by: Anson Huang <b20788@freescale.com>
ENGR00273073-1 arm: add cpu idle notification callback
Some modules may need to know cpu idle status and take
actions before and after cpu idle, so we can add
notification callback when enter/exit cpu idle, then
modules only need to register this notification callback,
everytime cpu enter/exit idle, the callback chain will be
executed.
Currently only cpufreq interactive governor use this
notification, as it wants to save power, the timers of
interactive governor are only enabled when cpu is not in idle.
Liu Ying [Tue, 25 Jun 2013 09:13:33 +0000 (17:13 +0800)]
ENGR00268508 backlight:Correct the setting for bd props.fb_blank
The patch of "ENGR00264855 backlight: Support backlight shared by
multiple fbs" doesn't consider that bd->props.fb_blank could be
shared by several framebuffers which use the same backlight device.
This causes the pwm backlight wrongly check the fb blank status.
This patch corrects the setting for the fb blank status by
considering all the framebuffers in question to fix the issue.
Liu Ying [Thu, 30 May 2013 05:56:17 +0000 (13:56 +0800)]
ENGR00264855 backlight: Support backlight shared by multiple fbs
One backlight device may shared by multiple framebuffers.
We don't hope blanking one of the framebuffers may turn the
backlight off for all the other framebuffers, since they are
likely active to show display content. This patch adds logic
to record each framebuffer's backlight usage to determine the
backlight device use count and whether the backlight should be
turned on or off.
Richard Zhu [Wed, 24 Jul 2013 06:15:29 +0000 (14:15 +0800)]
ahci_imx: add ahci sata support on imx platforms
imx6q contains one Synopsys AHCI SATA controller, But it can't share
ahci_platform driver with other controllers because there are some
misalignments of the generic AHCI controller - the bits definitions of
the HBA registers, the Vendor Specific registers, the AHCI PHY clock
and the AHCI signals adjustment window(GPR13 register).
- CAP_SSS(bit20) of the HOST_CAP is writable, default value is '0',
should be configured to be '1'
- bit0 (only one AHCI SATA port on imx6q) of the HOST_PORTS_IMPL
should be set to be '1'.(default 0)
- One Vendor Specific register HOST_TIMER1MS(offset:0xe0) should be
configured regarding to the frequency of AHB bus clock.
- Configurations of the AHCI PHY clock, and the signal parameters of
the GPR13
Setup its own ahci sata driver, contained the imx6q specific
initialized codes, re-use the generic ahci_platform driver, and keep
the generic ahci_platform driver clean as much as possible.
ENGR00240987: ARM: dts: enable LDB and LCD support for imx6qdl-sabresd
This is a fast-forward porting of LDB and LCD DTS changes from 3.5.7
kernel.
Along with the changes, the "&ldb" node gets removed from imx6q.dtsi,
since it's only used by community kernel and will conflict with our
internal LDB bindings.
While adding alias for ipu in imx6qdl.dtsi, it also sorts all those
aliases alphabetically.
ENGR00240987: video: port LDB and LCD FB display drivers from 3.5.7 kernel
This is a fast-forward porting of LDB and LCD frame buffer drivers from
3.5.7 kernel to kernel 3.10. The change set is kept as minimum as
possible with only making necessary code changes, which are mostly for
solving compile problems.
* Remove <mach/*> inclusions
* Drop __devinit and __devexit
* Drop vm flag VM_RESERVED
* Protect ldb_setup() with #ifndef MODULE to fix "warning: ‘ldb_setup’
defined but not used" in module build
* Remove fb_prepare_logo() and fb_show_logo() calls, because it breaks
module build, and penguin logo works fine without the calls in
mxc_ipuv3_fb.c
ENGR00240987: ipu: port ipuv3 driver from 3.5.7 kernel
This is a fast-forward porting of ipuv3 driver from 3.5.7 kernel to
kernel 3.10. The change set is kept as minimum as possible with only
making necessary code changes to adapt 3.10 kernel internal API and
framework updates. Everything else should be same as 3.5.7 one. The
change set consists of the following.
* Remove unused Kconfig options MXC_IPU_V3D, MXC_IPU_V3EX and
MXC_IPU_V3H
* Comment out busfreq calls
* Move ipu-v3.h into include/linux/, and remove all <mach/*> includes
* Drop __devinit and __devexit
* Remove assignment of pltfm_data->pg = imx6q_ipu_pg;
* Use generic device_reset() API rather than ipu_pltfm_data->init()
hook to reset IPU
* Includes <linux/sched/rt.h> ipu_device.c to fix undeclared
MAX_USER_RT_PRIO error
* Change compatible string to "fsl,imx6q-ipu" to align with community
kernel
* Define irq_sync before irq_err in DTS to align with community kernel
* Drop "ipu1_" and "ipu2_" from clock names to save the handling of the
second parameter of devm_clk_get()
* Remove the buggy csi_clk setup in ipu_clk_setup_enable() and validate
the clock before operate on it in ipu_csi_enable_mclk()
* Replace iram API (linux/iram_alloc.h) with generic memory pool API
(linux/genalloc.h) in VDOA driver
ARM: dts: imx: ocram size is different between imx6q and imx6dl
The ocram on imx6q is 256 KiB while on imx6dl it's 128 KiB. Let's
have separate node for imx6q and imx6dl. It also changes imx6q size
0x3f000 to 0x40000 to match the hardware.
ENGR00269945: ARM: imx: enable cpufreq and thermal support in defconfig
Enable cpufreq and thermal support in defconfig, so that cpufreq can be
used as the cpu_cooling device to throttle CPUs when passive trip point
gets crossed.
Shawn Guo [Mon, 24 Jun 2013 06:30:44 +0000 (14:30 +0800)]
thermal: add imx thermal driver support
This is based on the initial imx thermal work done by
Rob Lee <rob.lee@linaro.org> (Not sure if the email address is still
valid). Since he is no longer interested in the work and I have
rewritten a significant amount of the code, I just took the authorship
over from him.
It adds the imx thermal support using Temperature Monitor (TEMPMON)
block found on some Freescale i.MX SoCs. The driver uses syscon regmap
interface to access TEMPMON control registers and calibration data, and
supports cpufreq as the cooling device.
This makes function get_property() return the wrong frequency for given
cooling level if the frequency table is sorted in ascending. Fix it
by correcting the 'descend' check in if-condition to 'descend == -1'.
The CLKO is widely used by imx6q board designs to clock audio codec.
Since most codecs accept 24 MHz frequency, let's initially set up CLKO
with OSC24M (cko <-- cko2 <-- osc). Then those board specific CLKO
setup for audio codec can be removed.
The board dts files also need an update on cko reference in codec node.
The clock output on imx6q CCM_CLKO1 pad is not always cko1 clock, and
there is a multiplexer to select between cko1 and cko2. Add this
missing selection as the clock cko.
Sascha Hauer [Thu, 20 Jun 2013 15:34:31 +0000 (17:34 +0200)]
ARM: i.MX6: call ksz9021 phy fixup for all i.MX6 boards
In current U-Boot the sabrelite, nitrogen6x and titanium all need
the same fixup for the ksz9021 phy. Instead of limiting the fixup
to a single board apply them for all.
This part of bias settings are essential for WM8962 to power up. Without it
"wm8962 0-001a: DC servo timed out" might be prompted due to power-up failure
that happens to FLL if being used.
The driver's also bringing the bias down in the suspend path so it needs to be
powered up in the resume path for symmetry.
According to dapm_pre_sequence_async(), DAPM would call pm_runtime_get_sync()
to let driver finish the bias settings in pm_runtime_resume() before the bias
level being set to STANDBY. So no need to worry about disordered settings for
VMID of WM8962.
Signed-off-by: Nicolin Chen <b42378@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
ARM: dts: imx: remove old DMA binding data from gpmi node
After mxs-dma driver adopts generic DMA device tree binding, gpmi
channel interrupt number is defined in DMA controller node, and
channel ID is listed in "dmas" property. So the DMA channel interrupt
number in gpmi node "interrupts" property and fsl,gpmi-dma-channel which
are used by old customized DMA binding can be removed now.
ASoC: fsl: move fsl_ssi to generic DMA DT bindings
It removes the temporary custom DMA bindings from fsl_ssi driver and use
the generic one instead. It leaves imx-ssi drive unchanged regarding
those pcm flags by updating imx_pcm_dma_init() to let SSI driver decide
the flags.
With imx-pcm-dma moving to generic dmaengine pcm driver and the removal
of imx-pcm-audio/imx-fiq-pcm-audio platform device use, now imx-pcm
driver contains a few functions that are only used by imx-pcm-fiq.c.
Move these functions into imx-pcm-fiq.c and remove imx-pcm.c completely.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Rather than instantiating imx-fiq-pcm-audio to call imx_pcm_fiq_init(),
imx-ssi can just directly call it to save the use of imx-fiq-pcm-audio.
With this change, imx-ssi becomes not only a cpu DAI but also a platform
device, so updates platform device setup in eukrea-tlv320, phycore-ac97
and wm1133-ev1 accordingly.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Rather than instantiating imx-pcm-audio to call imx_pcm_dma_init(),
imx-ssi can just directly call it to save the use of imx-pcm-audio.
With this change, imx-ssi becomes not only a cpu DAI but also a
platform device, so updates platform device setup in imx-mc13783 and
mx27vis-aic32x4 accordingly.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Rather than instantiating imx-pcm-audio to call imx_pcm_dma_init(),
fsl_ssi can just directly call it to save the use of imx-pcm-audio.
With this change, fsl_ssi becomes not only a cpu DAI but also a platform
device, so updates platform device setup in imx-sgtl5000 accordingly.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Update imx-sdma driver to adopt generic DMA device tree bindings. It
calls of_dma_controller_register() with imx-sdma specific of_dma_xlate
to get the generic DMA device tree helper support. The #dma-cells for
imx-sdma must be 3, which includes request ID, peripheral type and
priority.
The existing way of requesting channel, clients directly call
dma_request_channel(), still work there, and will be removed after
all imx-sdma clients get converted to generic DMA device tree helper.
ENGR00269945: ARM: dts: add uart3 support for imx6qdl-sabreauto
On imx6qdl-sabreauto board, the pin function UART3_CTS is steered by the
GPIO4 of MAX7310 Expander B, while UART3_RXD and UART3_TXD are steered
by GPIO3 of MAX7310 Expander C. And both GPIOs need to be pulled high
to assert UART3 on the board.
ENGR00269945: ARM: dts: add max7310 support for imx6qdl-sabreauto
On imx6qdl-sabreauto board, there are three IO expanders implemented by
max7310, which are all controlled by I2C3. And GPIO5_4 is steering the
I2C3_SDA availability, while GPIO1_15 is used to reset max7310.
ENGR00269945: pinctrl: support pinctrl setting assertion via gpios
It's pretty common that on some reference design or validation boards,
one pin could be used by two devices on board, and the pin route is
controlled by a GPIO. So to assert the pin for given device, not only
the pinmux controller in SoC needs to be set up properly but also the
GPIO needs to be pulled up/down.
The patch adds support of a device tree property "pinctrl-assert-gpios"
under client device node. It plays pretty much like a board level pin
multiplexer, and steers the pin route by controlling the GPIOs. When
client device has the property represent in its node, pinctrl device
tree mapping function will firstly pull up/down the GPIOs to assert the
pins for the device at board level.
The pca953x type of devices, e.g. max7310, may have a reset which needs
to be handled to get the device start working. Add a device_reset()
call for that, and defer the probe if the reset controller for that is
not ready yet.
ENGR00269945: select ARCH_HAS_RESET_CONTROLLER for IMX
Move ARCH_HAS_RESET_CONTROLLER from HAVE_IMX_SRC to ARCH_MXC to have it
selected for the whole IMX family instead of SRC (System Reset
Controller), since GPIO could be another reset controller in many cases.
ENGR00269945: reset: add dummy device_reset() for !CONFIG_RESET_CONTROLLER build
Add dummy device_reset() function for !CONFIG_RESET_CONTROLLER build,
so that we do not have to add #ifdef CONFIG_RESET_CONTROLLER in every
single client device drivers that call the function.
ENGR00269945: reset: register gpio-reset driver in arch_initcall
It's a little bit late to register gpio-reset driver at module_init
time, because gpio-reset provides reset control via gpio for other
devices which are mostly probed at module_init time too. And it
becomes even worse, when the gpio comes from IO expander on I2C bus,
e.g. pca953x. In that case, gpio-reset needs to be ready before I2C
bus driver which is generally ready at subsys_initcall time. Let's
register gpio-reset driver in arch_initcall() to have it ready early
enough.
The defer probe mechanism is not used here, because a reset controller
driver should be reasonably registered early than other devices. More
importantly, defer probe doe not help in some nasty cases, e.g. the
gpio-pca953x device itself needs a reset from gpio-reset driver start
working.
ENGR00269945: reset: handle cansleep case in gpio-reset
Some gpio reset may be backed by a gpio that can sleep, e.g. pca953x
gpio output. For such gpio, gpio_set_value_cansleep() should be
called. Otherwise, the WARN_ON(chip->can_sleep) in gpiod_set_value()
will be hit. Add a gpio_cansleep() check to handle cansleep gpio.
Philipp Zabel [Thu, 30 May 2013 09:09:00 +0000 (11:09 +0200)]
reset: Add driver for gpio-controlled reset pins
This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The delay between assertion
and de-assertion of the reset signal can be configured via device tree.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
ARM: dts: imx: share pad macro names between imx6q and imx6dl
The imx6q and imx6dl are two pin-to-pin compatible SoCs. The same board
design can work with either chip plugged into the socket, e.g. sabresd
and sabreauto boards.
We currently define pin groups in imx6q.dtsi and imx6dl.dtsi
respectively because the pad macro names are different between two
chips. This brings a maintenance burden on having the same label point
to the same pin group defined in two places.
The patch replaces prefix MX6Q_ and MX6DL_ with MX6QDL_ for both SoCs
pad macro names. Then the pin groups becomes completely common between
imx6q and imx6dl and can just be moved into imx6qdl.dtsi, so that the
long term maintenance of imx6q/dt pin settings becomes easier.
Unfortunately, the change brings some dramatic diff stat, but it's all
about DTS file, and the ultimate net diff stat is good.
The following error randomly appears on an imx6q board where gpio is
used to implement card-detection when mounting EXT4 rootfs during boot.
mmc1: Card removed during transfer!
mmc1: Resetting controller.
mmcblk0: unknown error -123 sending read/write command, card status 0x900
end_request: I/O error, dev mmcblk0, sector 106744
EXT4-fs error (device mmcblk0p2): ext4_find_entry:1312: inode #5011: comm swapper/0: reading directory lblock 0
It turns out that the error message comes from the card removal check
in function sdhci_card_event(). While we have a well implemented
function sdhci_do_get_cd() handling all the possible cases of
CD, the current code only checks controller internal CD case. That
causes problem for other CD cases like gpio on above imx6q board.
Improve the check by using sdhci_do_get_cd() to cover all possible CD
cases, so that above error on the imx6q board gets fixed.
Vincent Stehlé [Wed, 10 Jul 2013 09:45:46 +0000 (11:45 +0200)]
ARM: imx: fix imx_init_l2cache storage class
This fixes the following compilation error:
arch/arm/mach-imx/system.c:101:123: error: static declaration of
‘imx_init_l2cache’ follows non-static declaration
In file included from arch/arm/mach-imx/system.c:32:0:
arch/arm/mach-imx/common.h:165:13: note: previous declaration of
‘imx_init_l2cache’ was here
arch/arm/mach-imx/system.c:101:123: warning: ‘imx_init_l2cache’ defined but
not used [-Wunused-function]
Signed-off-by: Vincent Stehlé <vincent.stehle@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
The fec/enet driver calculates MDC rate with the formula below.
ref_freq / ((MII_SPEED + 1) x 2)
The ref_freq here is the fec internal module clock, which is missing
from clk-vf610 clock driver right now. And clk-vf610 driver mistakenly
supplies RMII clock (50 MHz) as the source to fec. This results in the
situation that fec driver gets ref_freq as 50 MHz, while physically it
runs at 66 MHz (fec module clock physically sources from ipg which runs
at 66 MHz). That's why software expects MDC runs at 2.5 MHz, while the
measurement tells it runs at 3.3 MHz. And this causes the PHY KSZ8041
keeps swithing between Full and Half mode as below.
libphy: 400d0000.etherne:00 - Link is Up - 100/Full
libphy: 400d0000.etherne:00 - Link is Up - 100/Half
libphy: 400d0000.etherne:00 - Link is Up - 100/Full
libphy: 400d0000.etherne:00 - Link is Up - 100/Half
libphy: 400d0000.etherne:00 - Link is Up - 100/Full
libphy: 400d0000.etherne:00 - Link is Up - 100/Half
Add the missing module clock for ENET0 and ENET1, and correct the clock
supplying in device tree to fix above issue.
Thanks to Alison Wang <b18965@freescale.com> for debugging the issue.
Liu Ying [Thu, 4 Jul 2013 09:57:17 +0000 (17:57 +0800)]
ARM: imx6: change some clocks to fixup clocks
All the clocks controlled by the register 'CCM Serial Clock
Multiplexer Register 1' should be fixup clocks. This patch
changes those clocks from basic multiplexer or divider clocks
to fixup clocks.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Liu Ying [Thu, 4 Jul 2013 09:35:46 +0000 (17:35 +0800)]
ARM: imx: add common clock support for fixup mux
One register may have several fields to control some clocks. It
is possible that the read/write values of some fields may map to
different real functional values, so writing to the other fields
in the same register may break a working clock tree. A real case
is the aclk_podf field in the register 'CCM Serial Clock Multiplexer
Register 1' of i.MX6Q/SDL SoC. This patch introduces a fixup hook
for multiplexer clock which is called before writing a value to
clock registers to support this kind of multiplexer clocks.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Liu Ying [Thu, 4 Jul 2013 09:22:26 +0000 (17:22 +0800)]
ARM: imx: add common clock support for fixup div
One register may have several fields to control some clocks. It
is possible that the read/write values of some fields may map to
different real functional values, so writing to the other fields
in the same register may break a working clock tree. A real case
is the aclk_podf field in the register 'CCM Serial Clock Multiplexer
Register 1' of i.MX6Q/SDL SoC. This patch introduces a fixup hook
for divider clock which is called before writing a value to clock
registers to support this kind of divider clocks.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
ARM: imx: let L2 initialization be a common function
Move imx6q L2 initialization function imx6q_init_l2cache() into
system.c, and rename it imx_init_l2cache(), so that other platforms
other than imx6q can also use the function.
The MLB PLL clock's operation doesn't fit for clock framework and
it should be handled internally in MLB driver.
Remove initialization of pll8_mlb clock device but leave its
declaration in mx6q_clks to avoid affecting imx6q clock numbering.
[ shawn.guo: The MLB PLL is currently implemented as an imx pllv3
clock. But it does not really make too much sense, because the PLL
does not have ENABLE, POWERDOWN and DIV_SELECT bits.
Also commit 0e57446 (ARM i.MX6: correct MLB clock configuration)
already removes the incorrect parenting on MLB PLL, now it's safe
and reasonable to remove the PLL completely from clock framework,
and let MLB driver handle the PLL per its particular need. ]
The CCM_CBCMR register (address 0x02C4018) has different meaning
between the i.MX6 Quad/Dual and the i.MX6 Solo/DualLite.
Compared to the i.MX6 Quad/Dual, the CCM_CBCMR register in the
i.MX6 Solo/DualLite doesn't have a gpu3d_shader configuration and
moves the gpu2_core configuration at that place.
Handle these i.MX6 Quad/Dual vs. i.MX6 Solo/DualLite clock differences
by using cpu_is_mx6dl().
serial: fsl_lpuart: restore UARTCR2 after watermark setup is done
Function lpuart_setup_watermark() clears some bits in register UARTCR2
before writing FIFO configuration registers as required by hardware.
But it should restore UARTCR2 after that. Otherwise, we end up changing
UARTCR2 register when setting up watermark, and that is not really
desirable. At least, when low-level debug and earlyprint is enabled,
serial console is broken due to it.
Fix the problem by restoring UARTCR2 register at the end of function
lpuart_setup_watermark().
projects / karo-tx-linux.git / log