Robin Gong [Fri, 15 Nov 2013 10:29:03 +0000 (18:29 +0800)]
ENGR00288351 sabresd_battery: fix usb charger detect when resume back on mx6sl
Fix below redundant log after first resume back on mx6slevk:
max8903-charger max8903.12: USB Charger Connected
It's caused by not add enough prepare for uok&dok which are connected, such as
i.MX6SL-EVK. In this case the board only support DC charger detect, so we
didn't need judge the uok pin for USB charger detect, although uok share with
dok pin.
Fugang Duan [Mon, 18 Nov 2013 02:17:03 +0000 (10:17 +0800)]
ENGR00288342 net:fec_ptp: fix the potential issue for storing timestamp
The timestamps generated in the i.MX drivers are generated by the
nanoseconds part coming from the 1588 clock. But the number of seconds
are maintained in a private structure of the interface. Those are
updated in a 1588 clock rollover interrupt.
The timestamp is generated right before a rollover of a second and the
timestamp value is constructed afterwards. Therefore the bigger part of
the timestamp is wrong (the second).
Robby Cai [Fri, 15 Nov 2013 09:21:16 +0000 (17:21 +0800)]
ENGR00288196 ARM: dts: fix epdc and csi conflict on imx6sl evk
There is pinmux conflict for EPDC and I2C3 on imx6sl soc.
While on imx6sl evk board, the camera is attached on I2C3 bus, so the
EPDC function and CSI function can not be used at same time.
This patch removes the conflict in imx6sl-evk.dts file for EPDC function
and adds a new dts file for CSI function.
ENGR00279980 ubi: attach: do not return -EINVAL if the mtd->numeraseregions is 1
If the master mtd does not have any slave mtd partitions,
and its numeraseregions is one(only has one erease block), and
we attach the master mtd with : ubiattach -m 0 -d 0
We will meet the error:
-------------------------------------------------------
root@freescale ~$ ubiattach /dev/ubi_ctrl -m 0 -d 0
UBI: attaching mtd0 to ubi0
UBI error: io_init: multiple regions, not implemented
ubiattach: error!: cannot attach mtd0
error 22 (Invalid argument)
-------------------------------------------------------
In fact, if there is only one "erase block", we should not
prevent the attach.
Anson Huang [Fri, 15 Nov 2013 14:35:20 +0000 (09:35 -0500)]
ENGR00288133 arm: imx: correct arm clock usecount for i.MX6Q/DL
ARM clock is sourcing from pll1_sw, and pll1_sw can be either
from pll1_sys or step, so we should enable arm clock during
clock initialization instead of pll1_sys, otherwise, arm clock's
usecount would be incorrect and PLL1 will never be disabled even
it is not used.
Peter Chen [Sat, 9 Nov 2013 00:08:10 +0000 (08:08 +0800)]
ENGR00286962-2 usb: chipidea: fix the system will be deadlock with ID wakeup
When we plug in Micro B-TO-A cable at OTG port with u-disk connected,
and enable USB ID wakeup, then, suspend the system, the system
will be deadlock during the resume. See below Sysrq dump.
If the flush_work at block layer is called after system resume
has completed, this problem has fixed (using pm_mutex at ci_otg_work).
It seems if the task is rescheduled before the system resume has
completed (after thaw_processes), it will cause the system dead lock.
Unless the task has been freezed explicitly before system suspend.
The fixes uses wait_event_freezable to wait event, it should call
try_to_freeze during the freeze_processes, and task will not be
scheduled until thaw_processes has called (for frozen process, it will
call wake_up_process explicitly).
--------------------------------------Sysrq dump------------------------------------------
sh D 80600860 0 1016 1014 0x00000000
[<80600860>] (__schedule+0x1e0/0x5d8) from [<80601274>] (schedule_preempt_disabled+0xc/0x10)
[<80601274>] (schedule_preempt_disabled+0xc/0x10) from [<805ffe00>] (__mutex_lock_slowpath+0x154/0x1f4)
[<805ffe00>] (__mutex_lock_slowpath+0x154/0x1f4) from [<805ffef0>] (mutex_lock+0x50/0x54)
[<805ffef0>] (mutex_lock+0x50/0x54) from [<802f7f84>] (dpm_complete+0xac/0x1ac)
[<802f7f84>] (dpm_complete+0xac/0x1ac) from [<80057a34>] (suspend_devices_and_enter+0x1bc/0x330)
[<80057a34>] (suspend_devices_and_enter+0x1bc/0x330) from [<80057d50>] (pm_suspend+0x1a8/0x240)
[<80057d50>] (pm_suspend+0x1a8/0x240) from [<80056a8c>] (state_store+0x6c/0xbc)
[<80056a8c>] (state_store+0x6c/0xbc) from [<802586c0>] (kobj_attr_store+0x14/0x20)
[<802586c0>] (kobj_attr_store+0x14/0x20) from [<80117374>] (sysfs_write_file+0xfc/0x17c)
[<80117374>] (sysfs_write_file+0xfc/0x17c) from [<800bdcc0>] (vfs_write+0xbc/0x184)
[<800bdcc0>] (vfs_write+0xbc/0x184) from [<800be058>] (SyS_write+0x40/0x68)
[<800be058>] (SyS_write+0x40/0x68) from [<8000e040>] (ret_fast_syscall+0x0/0x30)
Sandor Yu [Thu, 14 Nov 2013 08:48:42 +0000 (16:48 +0800)]
ENGR00288021 IPUv3 disp:get the integer part of div correctly
TV will show 639x480p60 when HDMI output 640x480p60.
The same issue can be found when pixel clock sources from ipu internally.
All video modes whose pixel clocks derive from DI clock work OK.
It is caused by the wrong parent clock rate the driver gets.
Fix the issue by getting the right parent clock(ipu->pixel_clk_sel).
Fugang Duan [Thu, 14 Nov 2013 09:21:14 +0000 (17:21 +0800)]
ENGR00288046: net:fec_ptp: fix WARNING caused by mutex_trylock run in interrupt context
Kernel warning dump by enable kernel config "CONFIG_DEBUG_MUTEXES":
------------[ cut here ]------------
WARNING: at kernel/mutex.c:577 mutex_trylock+0x180/0x1d0()
DEBUG_LOCKS_WARN_ON(in_interrupt())
Modules linked in:
CPU: 0 PID: 68 Comm: kworker/0:2 Tainted: G W 3.10.17-16855-ga44de14 #1325
Workqueue: events phy_state_machine
[<80014cbc>] (unwind_backtrace+0x0/0x138) from [<8001251c>]
(show_stack+0x10/0x14)
[<8001251c>] (show_stack+0x10/0x14) from [<80026754>]
(warn_slowpath_common+0x4c/0x68)
[<80026754>] (warn_slowpath_common+0x4c/0x68) from [<80026804>]
(warn_slowpath_fmt+0x30/0x40)
[<80026804>] (warn_slowpath_fmt+0x30/0x40) from [<8069f6b0>]
(mutex_trylock+0x180/0x1d0)
[<8069f6b0>] (mutex_trylock+0x180/0x1d0) from [<804dce7c>]
(clk_prepare_lock+0xc/0xd8)
[<804dce7c>] (clk_prepare_lock+0xc/0xd8) from [<804ddbcc>]
(clk_get_rate+0xc/0x5c)
[<804ddbcc>] (clk_get_rate+0xc/0x5c) from [<803b7528>]
(fec_ptp_start_cyclecounter+0x1c/0x198)
[<803b7528>] (fec_ptp_start_cyclecounter+0x1c/0x198) from [<803b5928>]
(fec_restart+0x6e8/0x870)
[<803b5928>] (fec_restart+0x6e8/0x870) from [<803b5d50>]
(fec_enet_adjust_link+0x7c/0xb4)
[<803b5d50>] (fec_enet_adjust_link+0x7c/0xb4) from [<803b07b8>]
(phy_state_machine+0xfc/0x394)
[<803b07b8>] (phy_state_machine+0xfc/0x394) from [<8003f03c>]
(process_one_work+0x198/0x428)
[<8003f03c>] (process_one_work+0x198/0x428) from [<8003fd24>]
(worker_thread+0x144/0x3a4)
[<8003fd24>] (worker_thread+0x144/0x3a4) from [<800458d8>]
(kthread+0xa4/0xb0)
[<800458d8>] (kthread+0xa4/0xb0) from [<8000ebd8>] (ret_from_fork+0x14/0x3c)
---[ end trace d1930b3e1c195329 ]---
Root cause:
Worker thread call netif_tx_lock_bh() to diable the softirq preempt, and
then call clk_get_rate() to get ptp clock rate.
In fact, netif_tx_lock_bh()->local_bh_disable(), which make in_interrupt()
to be ture. clk_get_rate()->clk_prepare_lock()->mutex_trylock(), and
mutex_trylock() cannot use at interrupt context, otherwise there have
kernel dump.
Robin Gong [Thu, 14 Nov 2013 05:58:21 +0000 (13:58 +0800)]
ENGR00287983-2 imx restart: add another WDOG2 reset support for ldo-bypass
For ldo-bypass mode on i.MX6Q/DL sabresd board, we will use another WDOG2 to
reset external pmic to trigger POR event, rather than WDOG1 to trigger WDOG
event in ldo-enable mode. We need to consider it in common mxc_restart().
On i.MX6SL sabresd board we use WDOG1 to trigger WDOG event both ldo-bypass and
ldo-enable mode.
Shawn Guo [Mon, 28 Oct 2013 08:37:12 +0000 (16:37 +0800)]
ARM: imx: remove imx_src_prepare_restart() call
There is ~10% possibility that the following emergency restart command
fails to reboot imx6q.
$ echo b > /proc/sysrq-trigger
The IMX restart routine mxc_restart() assumes that it will always run on
primary core, and will call imx_src_prepare_restart() to disable
secondary cores in order to get them come to online in the following
boot. However, the assumption is only true for normal kernel_restart()
case where migrate_to_reboot_cpu() will be called to migrate to primary
core, but not necessarily true for emergency_restart() case. So when
emergency_restart() calls into mxc_restart() on any secondary core,
system will hang immediately once imx_src_prepare_restart() is called
to disabled secondary cores. Since emergency_restart() is defined as a
function that is safe to call in interrupt context, we cannot just call
migrate_to_reboot_cpu() to fix the issue.
Fortunately, we just found that the issue can be fixed at imx6q platform
level. We used to call imx_src_prepare_restart() to disable all
secondary cores before resetting hardware. Otherwise, the secondary
will fail come to online in the reboot. However, we recently found that
after commit 6050d18 (ARM: imx: reset core along with enable/disable
operation) comes to play, we do not need to reset the secondary cores
any more. That said, mxc_restart() now can run on any core to reboot
the system, as long as we remove the imx_src_prepare_restart() call from
mxc_restart().
So let's simply remove imx_src_prepare_restart() call to fix the above
emergency restart failure.
Reported-by: Jiada Wang <jiada_wang@mentor.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
(cherry picked from commit e2eb7f22c90ab47cce77c6836183fa5e684489d1)
Shawn Guo [Sun, 6 Oct 2013 08:47:46 +0000 (16:47 +0800)]
ARM: imx: replace imx6q_restart() with mxc_restart()
The imx6q_restart() works fine with normal reboot but will run into
problem with emergency reboot like sysrq-b. In that case, of_iomap()
gets called from interrupt context and hence triggers the BUG_ON in
__get_vm_area_node().
Actually, since commit c1e31d1 (ARM: imx: create
mxc_arch_reset_init_dt() for DT boot), imx6q/dl should try to use
mxc_restart() by calling mxc_arch_reset_init_dt() beforehand, where
things like of_iomap() can be done.
The patch updates mxc_restart() a little bit to get it work for imx6q/dl
and kill imx6q_restart() completely.
Huang Shijie [Thu, 7 Nov 2013 10:07:38 +0000 (18:07 +0800)]
mtd: gpmi: add a new DT property to use the datasheet's minimum required ECC
In default way, we use the ecc_strength/ecc_step size calculated by ourselves
and use all the OOB area.
This patch adds a new property : "fsl,use-minimum-ecc"
If we enable it, we will firstly try to use the datasheet's minimum required
ECC provided by the MTD layer (the ecc_strength_ds/ecc_step_ds fields
in the nand_chip{}). So we may have free space in the OOB area by using the
minimum ECC, and we may support JFFS2 with some SLC NANDs, such as Micron's
SLC NAND.
If we fail to use the minimum ECC, we will use the legacy method to calculate
the ecc_strength and ecc_step size.
Signed-off-by: Huang Shijie <b32955@freescale.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Fabio Estevam [Fri, 8 Nov 2013 01:28:43 +0000 (23:28 -0200)]
mtd: gpmi-lib: Make checkpatch happy
Fix the following checkpatch warnings:
WARNING: line over 80 characters
#268: FILE: mtd/nand/gpmi-nand/gpmi-lib.c:268:
+ * consecutive reboots. The latter case has not been seen on the MX23 yet,
WARNING: space prohibited before semicolon
#356: FILE: mtd/nand/gpmi-nand/gpmi-lib.c:356:
+ (target.tRHOH_in_ns >= 0) ;
WARNING: space prohibited before semicolon
#1006: FILE: mtd/nand/gpmi-nand/gpmi-lib.c:1006:
+ BF_GPMI_TIMING0_DATA_SETUP(hw.data_setup_in_cycles) ;
Nicolin Chen [Mon, 11 Nov 2013 08:31:22 +0000 (16:31 +0800)]
ENGR00286961-5 ASoC: fsl: set tdm slot number for imx-si476x
When using SSI I2S master mode, we need to decide the time slot number.
Because we use SSI normal mode to trick I2S signal, we here need to set
time slot number to two (left/right).
Acked-by: Wang Shengjiu <b02247@freescale.com> Signed-off-by: Nicolin Chen <b42378@freescale.com>
Nicolin Chen [Fri, 8 Nov 2013 08:38:43 +0000 (16:38 +0800)]
ENGR00286961-4 ASoC: fsl_ssi: add monaural audio support
We use SSI's normal mode to trick I2S signal by fetching data only from
one side of time slot so that we can purely get or put the monaural audio
data.
Acked-by: Wang Shengjiu <b02247@freescale.com> Signed-off-by: Nicolin Chen <b42378@freescale.com>
Nicolin Chen [Fri, 8 Nov 2013 08:26:25 +0000 (16:26 +0800)]
ENGR00286961-3 ARM: dtsi: imx6qdl: Use non-default value for audmux pinctrl
It's better to specify pinctrl value so that we can clearly know what the
exact configuration they are. Also, when we need to set pinctrl state from
another state to default one, it must be given the exact values of pinctrl.
And this patch also sets TXD iomux to PUE keep. This would force TXD pin not
to pull down its signal during an unused state so that it won't distort its
output signal during that state.
Acked-by: Wang Shengjiu <b02247@freescale.com> Signed-off-by: Nicolin Chen <b42378@freescale.com>
Nicolin Chen [Fri, 8 Nov 2013 07:48:42 +0000 (15:48 +0800)]
ENGR00286961-2 ASoC: fsl_ssi: Move DC configuration to set_dai_tdm_slot()
DC indicates Frame Rate Divider. By setting it we can get a desired
time slot numbers. Thus it should be more plausible to set DC in
set_dai_tdm_slot() instead of hw_params().
Acked-by: Wang Shengjiu <b02247@freescale.com> Signed-off-by: Nicolin Chen <b42378@freescale.com>
Nicolin Chen [Fri, 8 Nov 2013 07:38:18 +0000 (15:38 +0800)]
ENGR00286961-1 ASoC: fsl_ssi: add period size constraint for dual fifo mode
When using dual fifo mode, we need to keep period size as an even number
due to behavior of SDMA script. Otherwise, it might neglect the 2nd fifo
at each period when its size appears to be an odd number.
Acked-by: Wang Shengjiu <b02247@freescale.com> Signed-off-by: Nicolin Chen <b42378@freescale.com>
Huang Shijie [Tue, 12 Nov 2013 04:23:08 +0000 (12:23 +0800)]
mtd: gpmi: fix the NULL pointer
The imx23 board will check the fingerprint, so it will call the
mx23_check_transcription_stamp. This function will use @chip->buffers->databuf
as its buffer which is allocated in the nand_scan_tail().
Unfortunately, the mx23_check_transcription_stamp is called before the
nand_scan_tail(). So we will meet a NULL pointer bug:
This patch rearrange the init procedure:
Set the NAND_SKIP_BBTSCAN to skip the nand scan firstly, and after we
set the proper settings, we will call the chip->scan_bbt() manually.
Because dma-debug add new interfaces to debug dma mapping errors, pls refer
to: http://lwn.net/Articles/516640/
After dma mapping, it must call dma_mapping_error() to check mapping error,
otherwise the map_err_type alway is MAP_ERR_NOT_CHECKED, check_unmap() define
the mapping is not checked and dump the error msg.
So, and dma_mapping_error() checking to fix the WARNING.
Luwei Zhou [Mon, 11 Nov 2013 08:03:59 +0000 (16:03 +0800)]
ENGR00287256 mxc: mlb: Fix the SYNC mode hang issue when connected with MITB
This patch fixes the hang and crash issue of MLB SYNC mode in the driver.
The MITB will casue Sabreauto to hang and crash when testing the SYNC mode.
It is because MITB will cause something error on MLB bus when stopping the
SYNC test. The Sabreauto will keep entering error ISR and hang. Since we
don't know the details about MITB, we make drivers provide IO_CTRL
interface to disable the interrupt in SYNC mode.
Huang Shijie [Thu, 7 Nov 2013 09:46:37 +0000 (17:46 +0800)]
mtd: gpmi: only scan two chips for imx6
We cannot scan two chips for imx23 and imx28:
imx23: the Ready-Busy1 line is not connected for some board.
imx28: we do not set the pinctrl for Ready-Busy1
So we only scan two chips for imx6.
Signed-off-by: Huang Shijie <b32955@freescale.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Huang Shijie [Mon, 11 Nov 2013 04:13:45 +0000 (12:13 +0800)]
mtd: gpmi: fix kernel BUG due to racing DMA operations
[1] The gpmi uses the nand_command_lp to issue the commands to NAND chips.
The gpmi issues a DMA operation with gpmi_cmd_ctrl when it handles
a NAND_CMD_NONE control command. So when we read a page(NAND_CMD_READ0)
from the NAND, we may send two DMA operations back-to-back.
If we do not serialize the two DMA operations, we will meet a bug when
1.1) we enable CONFIG_DMA_API_DEBUG, CONFIG_DMADEVICES_DEBUG,
and CONFIG_DEBUG_SG.
1.2) Use the following commands in an UART console and a SSH console:
cmd 1: while true;do dd if=/dev/mtd0 of=/dev/null;done
cmd 1: while true;do dd if=/dev/mmcblk0 of=/dev/null;done
The kernel log shows below:
-----------------------------------------------------------------
kernel BUG at lib/scatterlist.c:28!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
.........................
[<80044a0c>] (__bug+0x18/0x24) from [<80249b74>] (sg_next+0x48/0x4c)
[<80249b74>] (sg_next+0x48/0x4c) from [<80255398>] (debug_dma_unmap_sg+0x170/0x1a4)
[<80255398>] (debug_dma_unmap_sg+0x170/0x1a4) from [<8004af58>] (dma_unmap_sg+0x14/0x6c)
[<8004af58>] (dma_unmap_sg+0x14/0x6c) from [<8027e594>] (mxs_dma_tasklet+0x18/0x1c)
[<8027e594>] (mxs_dma_tasklet+0x18/0x1c) from [<8007d444>] (tasklet_action+0x114/0x164)
-----------------------------------------------------------------
1.3) Assume the two DMA operations is X (first) and Y (second).
The root cause of the bug:
Assume process P issues DMA X, and sleep on the completion
@this->dma_done. X's tasklet callback is dma_irq_callback. It firstly
wake up the process sleeping on the completion @this->dma_done,
and then trid to unmap the scatterlist S. The waked process P will
issue Y in another ARM core. Y initializes S->sg_magic to zero
with sg_init_one(), while dma_irq_callback is unmapping S at the same
time.
See the diagram:
ARM core 0 | ARM core 1
-------------------------------------------------------------
(P issues DMA X, then sleep) --> |
|
(X's tasklet wakes P) --> |
|
| <-- (P begin to issue DMA Y)
|
(X's tasklet unmap the |
scatterlist S with dma_unmap_sg) --> | <-- (Y calls sg_init_one() to init
| scatterlist S)
|
[2] This patch serialize both the X and Y in the following way:
Unmap the DMA scatterlist S firstly, and wake up the process at the end
of the DMA callback, in such a way, Y will be executed after X.
After this patch:
ARM core 0 | ARM core 1
-------------------------------------------------------------
(P issues DMA X, then sleep) --> |
|
(X's tasklet unmap the |
scatterlist S with dma_unmap_sg) --> |
|
(X's tasklet wakes P) --> |
|
| <-- (P begin to issue DMA Y)
|
| <-- (Y calls sg_init_one() to init
| scatterlist S)
|
- EPDC firmware build was breaking due to binary build pre-empting
the conversion from .fw.ihex->.fw. Resolve this by forcing
firmware objects to be built in order.
The kernel panic is caused by the sg_buf is not set correctly with the
following code when compiled with Yocto GCC 4.8.1:
drivers/net/wireless/ath/ath6kl/hif.h:
struct hif_scatter_req {
struct list_head list;
/* address for the read/write operation */
u32 addr;
...
/* bounce buffer for upper layers to copy to/from */
u8 *virt_dma_buf;
struct hif_scatter_item scat_list[1];
u32 scat_q_depth;
};
(Note: the scat_req.scat_list[] will dynamiclly grow with run-time)
drivers/net/wireless/ath/ath6kl/sdio.c: ath6kl_sdio_setup_scat_data(...)
/* assemble SG list */
for (i = 0; i < scat_req->scat_entries; i++, sg++) {
ath6kl_dbg(ATH6KL_DBG_SCATTER, "%d: addr:0x%p, len:%d\n",
i, scat_req->scat_list[i].buf,
scat_req->scat_list[i].len);
The GCC 4.8.1 compiler will not do the for-loop till scat_entries, instead,
it only run one round loop. This may be caused by that the GCC 4.8.1 thought
that the scat_list only have one item and then no need to do full iteration,
but this is simply wrong by looking at the assebly code. This will cause the
sg buffer not get set when scat_entries > 1 and thus lead to kernel panic.
This patch is a workaround to the GCC 4.8.1 complier issue by passing the
entry address of the scat_req->scat_list to the for-loop and interate it,
then, GCC 4.8.1 will do the full for-loop correctly.
(Note: This issue not observed with GCC 4.7.2, only found on the GCC 4.8.1)
This patch does not change any function logic and no any performance downgrade.
Dong Aisheng [Mon, 11 Nov 2013 08:44:19 +0000 (16:44 +0800)]
ENGR00287331-3 sdhci-esdhc-imx: do not need disable clock during remove function
Since the clock is managed by runtime pm currently, we do not need
disable it again during driver remove function, or it will cause
clock disable count mismatch issue since the clocks have already been disabled.
mx6slevk:/sys/bus/platform/drivers/sdhci-esdhc-imx# echo 2194000.usdhc > unbind
mmc1: card aaaa removed
------------[ cut here ]------------
WARNING: at drivers/clk/clk.c:780 clk_disable+0x18/0x24()
....
Anson Huang [Fri, 8 Nov 2013 19:59:05 +0000 (14:59 -0500)]
ENGR00286960-2 arm: imx: improve status check of clock gate
For ccm clock gate, both 2b'11 and 2b'01 should be treated
as clock enabled, see below description in CCM:
2b'00: clock is off during all modes;
2b'01: clock is on in run mode, but off in wait and stop mode;
2b'10: Not applicable;
2b'11: clock is on during all modes, except stop mode.
Anson Huang [Fri, 8 Nov 2013 19:54:31 +0000 (14:54 -0500)]
ENGR00286960-1 arm: imx: initialize clock gate status
Some clocks gates need to be set to 2b'01 to allow CCM
auto disabling them when system enters WAIT mode, this
setting can save many runtime power. These clock gates
are normally always enabled, so no need to add another
status for clk gate enable function, just set them to
right status when system boot up is good enough.
Anson Huang [Thu, 7 Nov 2013 20:38:20 +0000 (15:38 -0500)]
ENGR00286744-3 arm: imx: optimize power number for busfreq
i.MX6DL's axi clock is sourcing from pfd540 by default,
need to switch axi clock from pfd540 to periph when system
enters low bus mode, this is to allow pfd540 to be disabled,
and it also keeps clk tree correct.
Anson Huang [Thu, 7 Nov 2013 19:06:00 +0000 (14:06 -0500)]
ENGR00286744-1 arm: imx: add necessary interface for pfd
Common clk framework will disable unused clks only if
they are enabled by default, so we need to add is_enabled
callback for clk framework to get clks' status.
pfd clocks are enabled by default, so we need to add this
interface for common clk framework to disable unused pfds.
ENGR00286345 [iMX6DL] Fixed random hang bug in bus freq driver
Incorrect clock disable of PLL2 caused random hangs during
DDR freq change in iMX6DL.
Remove PERCLK freq change code as this is not required for TO1.1
and later.
This patch fixes the HC ctrl_2 programming where, in case of
SDR104 and HS200, we have to write 100b in the the UHS Mode
bits. We wrote 101b that is reserved from Arasan Specs.
Reported-by: Youssef Triki <youssef.triki@st.com> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 599115686d8f62999a871f7d7ee87de3b939b258)
Adrian Hunter [Mon, 6 May 2013 09:17:32 +0000 (12:17 +0300)]
mmc: sdhci: add ability to stay runtime-resumed if the card is powered up
If card power is dependent on SD bus power then the host controller
must not be runtime suspended while the card is powered up. Add
the ability to stay runtime-resumed in that case and enable it with a new
quirk SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit f0710a557cb17746b09234f01073a2cdafe4f4a5)
Dong Aisheng [Fri, 8 Nov 2013 07:51:10 +0000 (15:51 +0800)]
ENGR00286971-2 dts: imx6-sabreauto: disabled flexcan when max7310 is gone
Flexcan transceiver is using GPIOs from max7310 on i2c3.
Since max7310 is gone on below dts files, so there's no reason
to keep flexcan alive in those dts files.
Note: since flexcan1 is disabled by default, so did not need
to add it.
Dong Aisheng [Fri, 8 Nov 2013 07:48:23 +0000 (15:48 +0800)]
ENGR00286971-1 imx6q: add sanity check for getting gpio for flexcan
This is used to avoid a warning:
WARNING: at /home/b29397/work/projects/linux-2.6-imx/drivers/gpio/gpiolib.c:126
gpio_to_desc+0x30/0x44()
invalid GPIO -517
Modules linked in:
....
gpiod_request: invalid GPIO
Alexey Neyman [Wed, 6 Nov 2013 03:40:36 +0000 (19:40 -0800)]
mmc: sdhci: Avoid needless loop while handling SDIO interrupts in sdhci_irq()
Ignore Card Interrupt bit in the interrupt status if we already know that
mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). This
avoids a needless loop in sdhci_irq() repeatedly reading interrupt status
and doing nothing.
Since we're using common esdhc_send_command for tuning commands and
the core code will call pm_runtime_put after command is finished.
So we add a pm_runtime_get_sync here to get the blance.
Dong Aisheng [Wed, 30 Oct 2013 10:48:52 +0000 (18:48 +0800)]
mmc: sdhci-esdhc-imx: clear SDHCI_CTRL_EXEC_TUNING should not affect other bits
Current code will clear all turning related bits like ESDHC_STD_TUNING_EN
and ESDHC_MIX_CTRL_FBCLK_SEL when clear SDHCI_CTRL_EXEC_TUNING.
This may cause the card which has already passed the turning to become
unwork since the turning status lost.
We observed this failure when enable runtime pm.
BTW, imx needs to enable ESDHC_MIX_CTRL_FBCLK_SEL bit for turned clock.
The FBCLK_SEL will be cleared when SDHCI_CTRL_TUNED_CLK is cleared
and SDHCI_CTRL_EXEC_TUNING is not set.
This is used in case we change to another normal card from a UHS card
in the same slot. FBCLK_SEL is not needed for normal card.
After that, SDHCI_CTRL_EXEC_TUNING will only affect ESDHC_MIX_CTRL_EXE_TUNE.
Clearing it does not affect the turned card to remain working on UHS mode.
Dong Aisheng [Wed, 30 Oct 2013 08:54:09 +0000 (16:54 +0800)]
mmc: sdhci-esdhc-imx: tuning bits should not be cleared during reset
We should not clear tuning bits during reset or the SD3.0/eMMC4.5 card
working on UHS mode may not work after reset since the former tuning
settings was lost.
Dong Aisheng [Wed, 16 Oct 2013 08:48:39 +0000 (16:48 +0800)]
mmc: core: mmc DDR mode should not depend on UHS_DDR50
The MMC_CAP_UHS_DDR50 must work on 1.8v.
However, the eMMC DDR mode can work on either 1.8v or 3.3v and
should not depend on UHS_DDR50.
So get rid of this limitation to let controller without 1.8v
signal voltage support can also work for eMMC DDR mode if it claims.
Dong Aisheng [Fri, 18 Oct 2013 11:36:50 +0000 (19:36 +0800)]
mmc: sdhci: clear auto cmd setting bits for no data cmds
The auto cmd settings bits should be cleared before sending new commands
or we may receive command timeout error for normal commands due to wrongly
pre-sent auto cmd.
e.g. we receive CMD13 timeout error due to ACMD23 is wrongly enabled
by former data commands.
Dong Aisheng [Wed, 6 Nov 2013 11:10:28 +0000 (19:10 +0800)]
ENGR00286724-8 can: flexcan: add self wakeup support
If wakeup is enabled, enter stop mode, else enter disabled mode.
Self wake can only work on stop mode.
For imx6q, the stop request has to be mannually assert on
IOMUX GPR13[28:29] register, we use syscon to control that bit.
Nicolin Chen [Thu, 7 Nov 2013 06:45:16 +0000 (14:45 +0800)]
ASoC: generic-dmaengine-pcm: Use SNDRV_DMA_TYPE_DEV_IRAM as default
When allocating memory space for DMA buffer, use on-chip internal SRAM
as default choice to save power. Since the core would allocate memory
from traditional external memory if iram allocation failed, we don't
need to worry about any side effect.
Signed-off-by: Nicolin Chen <b42378@freescale.com> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Mark Brown <broonie@linaro.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit ca2b029515b4a81bbedcffc69a5d9574bb5ba475)
Nicolin Chen [Tue, 5 Nov 2013 11:19:07 +0000 (19:19 +0800)]
ENGR00286273-1 dma: imx-sdma: allocate memory from iram
We try to allocate memory from SoC internal SRAM so that we can turn off
voltage of external DDR to save power. Surely, if we failed to get the
iram DT node or allocate memory due to no enough SRAM space, we would
allow SDMA driver to allocate memory in a traditional way.
Robby Cai [Wed, 6 Nov 2013 08:21:08 +0000 (16:21 +0800)]
ENGR00286462 mx6sl fb: fix runtime pm not work at probe time
For mxsfb, the lcdif controller is enabled (with clock enabled as well)
at probe time, but pm_runtime_enable() is called after its enablement,
thus runtime pm function only works at next enablement. The root cause
is that pm_runtime_get_sync() function need to be called after
pm_runtime_enable(). This patch fixes the problem by moving the
position of pm_runtime_enable() ahead.
For epdc fb, runtime pm may not work at probe time if DEFAULT_PANEL_HW_INIT
is turned on (off by default). Fix it for safety.
Peter Chen [Sun, 29 Sep 2013 03:07:23 +0000 (11:07 +0800)]
ENGR00286426-20 usb: chipidea: host: add quirk for ehci operation
For chipidea controller, it does not follow ehci spec strictly.
Taking resume signal as an example, it will stop resume signal about
20-21ms later automatically, but standard ehci spec says, the resume
signal is controlled by software (clear portsc.PORT_RESUME).
This operation causes some remote wakeup problems for high speed
devices due to host controller does not send SOF in time since
software can't guarantee set run/stop bit in time (run/stop bit
was cleared at the ehci suspend routine).
When software sets run/stop bit, it needs 1 SoF time to make it effect.
If we close the PHY clock just after setting run/stop bit, it does
not be set in practice, so a software delay is needed.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Peter Chen [Tue, 22 Oct 2013 06:17:10 +0000 (14:17 +0800)]
ENGR00286426-16 usb: chipidea: usbmisc_imx: remove the controller's clock info
Currently, the usbmisc is just an API supplier for controller
driver, the controller calls related APIs to handle different
things among the SoCs, before calling it, the clock must
be on. So the clock operation is useless for usbmisc, it also
increases the difficulties to manage the clock, especially at
runtime power management situation.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
When the controller is at suspend mode, it can be waken up by
external events (like vbus, dp/dm or id change). Once we receive
the wakeup interrupt, we need to resume the controller first, eg
open clocks, disable some wakeup settings, etc. After that, the
controller can receive the normal USB interrupts.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Peter Chen [Thu, 26 Sep 2013 07:45:23 +0000 (15:45 +0800)]
ENGR00286426-13 usb: chipidea: Add power management support
This commit adds runtime and system power management support for
chipidea core. The runtime pm support is controlled by glue
layer, it can be enabled by flag CI_HDRC_SUPPORTS_RUNTIME_PM.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Peter Chen [Thu, 26 Sep 2013 13:10:53 +0000 (21:10 +0800)]
ENGR00286426-12 usb: phy-mxs: Add system suspend/resume API
We need this to keep PHY's power on or off during the system
suspend mode. If we need to enable USB wakeup, then we
must keep PHY's power being on during the system suspend mode.
Otherwise, we need to keep PHY's power being off to save power.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Peter Chen [Mon, 16 Sep 2013 05:52:16 +0000 (13:52 +0800)]
ENGR00286426-11 usb: phy-mxs: Add implementation of set_wakeup
When we need the PHY can be waken up by external signals,
we can call this API. Besides, we call mxs_phy_disconnect_line
at this API to close the connection between USB PHY and
controller, after that, the line state from controller is SE0.
Once the PHY is out of power, without calling mxs_phy_disconnect_line,
there are unknown wakeups due to dp/dm floating at device mode.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Peter Chen [Wed, 18 Sep 2013 06:19:28 +0000 (14:19 +0800)]
ENGR00286426-10 usb: phy: Add set_wakeup API
This API is used to set wakeup enable at PHY registers, in that
case, the PHY can be waken up from suspend due to external events,
like vbus change, dp/dm change and id change.
Signed-off-by: Peter Chen <peter.chen@freescale.com>