Peter Chen [Thu, 2 May 2013 01:04:18 +0000 (09:04 +0800)]
ENGR00261037-1: usb: usb host works abnormal after unload gadget module
If there is usb device on the OTG port when controller works
at host mode, and at this time, we unload gadget module, the
usbcmd.rs will be cleared, it is unexpected behavior.
When the controller works at one mode(eg, host mode), the register
should not be written by other mode driver (eg, devcie driver).
The OTG driver does not consider this situation, and current i.mx
FSL OTG driver does not support fully OTG function, so we remove
the caller at fsl_otg_set_peripheral which will touch controller
register.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Liu Ying [Tue, 23 Apr 2013 04:24:17 +0000 (12:24 +0800)]
ENGR00259949 mxc vout:fix screen tearing issue in ic bypass case
In ic bypass case, we put video buffers at a framebuffer display
channel directly. The display channel works at triple buffer
mode. To make sure a video buffer(buf N) has been shown on display
device, we at least need to wait for the second video buffer(buf N+2)
after the current buffer(buf N) is put on the display channel. Then,
the current buffer(buf N) can be added to the dequeue list, otherwise,
the user may get the buffer too early so that the buffer being shown
can be overwritten - screen tearing issue happens.
ASRC allocated memory for output buffer but didn't correctly free it.
This patch removed the input-buffer's incorrect double-free code,
and freed the output-buffer instead.
Liu Ying [Wed, 24 Apr 2013 06:55:46 +0000 (14:55 +0800)]
ENGR00260231 mxc vout:fill black correctly for more planar formats
In ic bypass mode, the display framebuffer pixel format will be
changed to the pixel format of the buffer queued by user. It could
be all the planar pixel formats. We will fall back to the wrong
black filling logic for UYVY and RGB pixel formats if the planar
pixel format is not NV12. This patch corrects the black filling
logic for the following planar pixel formats:
IPU_PIX_FMT_YUV420P2
IPU_PIX_FMT_YUV420P
IPU_PIX_FMT_YVU420P
IPU_PIX_FMT_YUV422P
IPU_PIX_FMT_YVU422P
IPU_PIX_FMT_YUV444P
Wayne Zou [Wed, 24 Apr 2013 01:06:36 +0000 (09:06 +0800)]
ENGR00259754 V4L2 output: Fix HDMI display green bar after video playback
After doing video playback with Bypass IC mode on HDMI display, there is
a green bar at the bottom of the display, it is caused by resetting
miscalculated display buffer size.
ENGR00260082 mx6sl_evk: Change wm8962's MCLK to 24MHz
The clock, output from wm8962's FLL, is sometimes inaccurate.
This's because 26MHz is not quite stable for wm8962's internal FLL,
So change to 24MHz, the value recommended by Wolfson,
which has been used on SabreSD for quite a long time.
Acked-by: Wang Shengjiu <b02247@freescale.com> Signed-off-by: Nicolin Chen <b42378@freescale.com>
Peter Chen [Tue, 16 Apr 2013 01:47:15 +0000 (09:47 +0800)]
ENGR00258491-2 msl-mx6: usb: put PHY to be out of low power explicitly
We have wrong understanding that reset controller will put PHY
to be out of low power automatically, but in fact, it is not.
So, we should put PHY to be out of low power explicitly if the
portsc.phcd = 1 before we need to access controller's register.
Some register writing will hang system (eg,PERIODICLISTBASE),
some reading will not get the correct value (eg, otgsc).
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Peter Chen [Fri, 12 Apr 2013 08:04:37 +0000 (16:04 +0800)]
ENGR00258491-1 usb: host: fix error at unload module path
- When take the PHY out of low power mode, it needs to
call PHY's API, only set controller register is
not enough for some platforms
- usb_put_hcd will free hcd, all hcd related operation should
be prior to it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
That patch will lead to kernel crash when doing video playback on video16 with
overlay on. The reason is that fb driver doesn't reallocate larger DMA buffer
requested by V4L2 driver, while IPU hardware write to large DMA address.
Other solution is needed for the original issue.
ENGR00259341 mx6: Need to keep WAIT mode fix bit set before standby
According to hardware design requirement, the WAIT mode setting bit17
need to be set if system enter suspend without ARM power gated, so in
standby mode, we can NOT clear this bit.
ENGR00259189 thermal:mx6: Make sure thermal alarm working safely
The thermal sensor's value will be updated even it is power down,
as thermal sensor's clock source is from PLL3, so there is chance
that PLL3 is disabled before thermal driver is probed during kernel
boot up, so the value in thermal sensor can be incorrect in this
PLL3 disabled window.
Previous flow of thermal driver probe routine will enable PLL3
clock, then set the thermal alarm value and enable the alarm irq,
there is no delay or check about the thermal sensor's value, only
when the thermal sensor's value is correct, its alarm function
can be enabled. As adding delay in the probe routine is not a
good option, so we move the enabling of thermal alarm function
into the get temperature routine, as after the thermal value is
read, the alarm function is safe enough, as the thermal sensor
will be always working right after a read if its clock is enabled.
Wayne Zou [Fri, 1 Mar 2013 08:05:47 +0000 (16:05 +0800)]
ENGR00239959 V4L2 output: Fix video playback bug if pulling window out of screen
Add strict input parameters check for v4l2 output drivers. The part of window
inside the display boundary is shown if pulling window out of screen.
About this issue: video playback error if pulling window out of screen
Using totem to play a video and using the mouse to pull the video window
out of the screen, it will print the follow errors:
imx-ipuv3 imx-ipuv3.0: ERR:[0xbad85200]-no:0x15c0 "wait_for_comp_timeo
ut" ret:0,line:2768
imx-ipuv3 imx-ipuv3.0: ERR: [0xbad85200] no-0x15c0, timeout:1000ms!
imx-ipuv3 imx-ipuv3.0: ERR: no-0x15c0,ipu_queue_task err:-110
mxc_v4l2_output mxc_v4l2_output.0: display work fail ret = -110
imx-ipuv3 imx-ipuv3.0: warning: disable ipu dma channel 21 during its busy state
Terry Lv [Tue, 16 Apr 2013 11:05:54 +0000 (19:05 +0800)]
ENGR00259008: mlb: reduce iram usage amount in async mode
In testing async mode on mx6q ard and mx6dl ard, driver always said "can
not alloc rx buffer".
Change async's ring buffer size from 2048 to 1536(MEP package size) and
reduce the extra ring buffer for drop package, now the iram usage amount
in async mode reduced from 34816 to 24576.
ENGR00258885 flexcan: fix errata ERR005641 that MB may fail to be sent
This is an issue from IC errata ERR005641 which is described as follows:
----------------------------------------------------------
FlexCAN does not transmit a message that is enabled to be transmitted
in a specific moment during the arbitration process. The following
conditions are necessary to have the issue.
- Only one MB is configured to be transmitted
- The write which enables the MB to be transmitted (write on Control status
word) happens during a specific clock during the arbitration process.
After this arbitration process occurs, the bus goes to Idle state and no
new message is received on bus.
For example:
1) MB13 is deactivated on RxIntermission (write 0x0 on CODE field from Control
Status word) - First write on CODE
2) Reconfigure the ID and data fields
3) Enable the MB13 to be transmitted on BusIdle (write 0xC on Code
field) - Second write on code
4) CAN bus keeps in Idle state
5) No write on Control status from any MB happens.
During the second write on code (step 3), the write must happen one clock
before the current MB13 is to be scanned by arbitration process.
In this case, it does not detect the new code (0xC) and no new arbitration is
scheduled.
The suggested workaround which is implemented in this patch is:
The workaround consists of executing two extra steps:
6. Reserve the first valid mailbox as an inactive mailbox (CODE=0b1000).
If RX FIFO is disabled, this mailbox must be MB0. Otherwise, the first
valid mailbox can be found by using table "RX FIFO filters" on FlexCAN3 chapter.
7. Write twice INACTIVE code (0b1000) into the first valid mailbox.
Note: The first mailbox cannot be used for reception or transmission process.
-------------------------------------------------------------
Note: Although the currently flexcan driver does not have the step 1 to run,
it's also possible to meet this issue in theory because we can not predict
when the arbitration is scheduled.
With a modified can-utils/canfdttest tool simulating Pingpong test, we were
able to reproduce this issue after running a about one day.
After applying this patch, we ran six days and did not see the issue happen
again on two mx6q sabrelite boards.
Reuben Dowle [Mon, 31 Oct 2011 22:18:03 +0000 (11:18 +1300)]
can: flexcan: Fix CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK
Currently the flexcan driver uses hardware local echo. This blindly
echos all transmitted frames to all receiving sockets, regardless what
CAN_RAW_RECV_OWN_MSGS and CAN_RAW_LOOPBACK are set to.
This patch now submits transmitted frames to be echoed in the transmit
complete interrupt, preserving the reference to the sending
socket. This allows the can protocol to correctly handle the local
echo.
Further this patch moves tx_bytes statistic accounting into the tx_complete
handler.
Signed-off-by: Reuben Dowle <reuben.dowle@navico.com>
[mkl: move tx_bytes accounting into tx_complete handler; cleanups] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: dev: let can_get_echo_skb() return dlc of CAN frame
can_get_echo_skb() is usually called in the TX complete handler.
The stats->tx_packets and stats->tx_bytes should be updated there, too.
This patch simplifies to figure out the size of the sent CAN frame.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
ENGR00257847-2 MX6Q/DL-Fix Ethernet performance issue when WAIT mode is active
All of the interrupts from the ENET block are not routed to
the GPC block. Hence ENET interrupts are not able to wake
up the SOC when the system is in WAIT mode. And the ENET
interrupt gets serviced only when another interrupt causes
the SOC to exit WAIT mode. This impacts the ENET performance.
To fix the issue two options:
1. Route the ENET interrupt to a GPIO. Need to enable the
CONFIG_MX6_ENET_IRQ_TO_GPIO in the config.
2. If the GPIO mechanism cannot be used and is not enabled
by the above mentioned config, the patch will disable entry
to WAIT mode until ENET clock is active. When the ENET clock
is disabled, WAIT mode will be automatically enetered.
ENGR00257847-1 MX6Q/DL-Fix Ethernet performance issue when WAIT mode is active
All of the interrupts from the ENET block are not routed to
the GPC block. Hence ENET interrupts are not able to wake
up the SOC when the system is in WAIT mode. And the ENET
interrupt gets serviced only when another interrupt causes
the SOC to exit WAIT mode. This impacts the ENET performance.
To fix the issue two options:
1. Route the ENET interrupt to a GPIO. Need to enable the
CONFIG_MX6_ENET_IRQ_TO_GPIO in the config.
This patch provides support for routing the ENET interrupt
to GPIO_1_6. Routing to this GPIO requires no HW board mods.
If the GPIO_1_6 is being used for some other peripheral,
this patch can be followed to route the ENET interrupt to
any other GPIO though a HW mode maybe required.
2. If the GPIO mechanism cannot be used and is not enabled
by the above mentioned config, the patch will disable entry
to WAIT mode until ENET clock is active. When the ENET clock
is disabled, WAIT mode will be automatically enetered.
Terry Lv [Fri, 12 Apr 2013 07:44:46 +0000 (15:44 +0800)]
ENGR00258357-5: mlb: Use circle buf macros to replace old ringbuf mechanism
Use circle buf to replace old ringbuf mechanism.
Change to use circle buffer in read, write, rx isr and tx isr functions.
In first design of MLB, it's using it's own mechanism to manage ring
buffer, like in mxc_mlb.c.
And then, I saw that kernel already had a serials of circ buffer macros
which can be used to manage ring buffers.
This patch is to use circle buffer macros to manage mlb internal ring
buffers.
For detail of circle buffers, you can refer to
linux-2.6-imx/Documentation/circular-buffers.txt.
Terry Lv [Fri, 12 Apr 2013 07:33:56 +0000 (15:33 +0800)]
ENGR00258357-4: mlb: Group static variables to structure mlb_data
Group static variables to structure mlb_data.
Use mlb_data as platform data to be passed to file operation
functions.
Change accordingly functions for this change.
Terry Lv [Fri, 12 Apr 2013 07:18:50 +0000 (15:18 +0800)]
ENGR00258357-3: mlb: Reset whole CDR in init function
Reset whole CDR in init function. This will make mlb connection to MITB
more stable.
This is a missed part in mx6 rm's mlb section, but new in mlb's latest
spec DS62420AP2.pdf 12.1.1-1.
Without this patch, mlb may receive irq from MITB during initialization.
It might cause some connection issue that mlb can't receive data
sometimes. It was treat to be MITB's fault before we get the latest
spec.
Terry Lv [Thu, 11 Apr 2013 09:05:00 +0000 (17:05 +0800)]
ENGR00256417: MLB: can't receive data in wait mode
For MLB uses iram for data transfer, and there's a missing of dependency
on iram in MLB's clock setting, MLB can't receive data in wait mode.
We need to add ocram clock dependency in MLB clock.
Peter Chen [Wed, 10 Apr 2013 07:18:39 +0000 (15:18 +0800)]
ENGR00257130-7 usb: host: Disable wakeup when switch PHY from off to on
Disable wakeup interrupt, since there is wakeup
when phcd from 1->0 if wakeup interrupt is enabled.
The unexpected wakeup can be disappeared using this fix.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Peter Chen [Tue, 9 Apr 2013 08:18:51 +0000 (16:18 +0800)]
ENGR00257130-6 mx6-msl: usb: Add 500us delay for phy stable time
The PHY needs 500us time to be stable when its clock
from off to on. If there is wakeup enable before the
PHY is stable, there will be an unexpected wakeup.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Peter Chen [Wed, 3 Apr 2013 08:36:45 +0000 (16:36 +0800)]
ENGR00257130-3 usb: host: open the PHY when changing wakeup setting
- Disable irq when we change wakeup setting as there is unexpected
interrupt when we power PHY but enables wakeup.
- Power PHY when we need to change wakeup setting, as some wakeup
settings at PHY domain.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Peter Chen [Wed, 3 Apr 2013 08:28:01 +0000 (16:28 +0800)]
ENGR00257130-2 msl: usb: Disable auto power PHY if usb wakeup disabled
- We need to disable auto power PHY if there is a wakeup at USB port,
but usb as wakeup source is disabled, otherwise, there will be unexpected
interrupt when the software thinks the controller is still at low power
mode.
- Rework usbh1_wakeup_event_clear. The old design was incorrect, align
it with usb_dr.c.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
mtd: fix recovery after failed write-buffer operation in cfi_cmdset_0002.c
When working on a problem with some flash chips that lock up during
write-buffer operations, I think there may be a bug in the linux
handling of chips using cfi_cmdset_0002.c.
The datasheets I have found for a number of these chips all specify that
when aborting a write-buffer command, it is not enough to use the
standard reset. Rather a "write-to-buffer-reset command" is needed.
This command is quite similar for all chips, the main variance seem to
be if the final 0xF0 can go to any address or must go to addr_unlock1.
The bug is then in the recovery handling when timing out at the end of
do_write_buffer, where using the normal reset command is not sufficient.
Without this change, if the write-buffer command fails then any
following operations on the flash also fail.
mtd: cfi_cmdset_0002: Micron M29EW bugfixes as per TN-13-07
Fix the following issues with Micron's (formerly Numonyx)
M29EW NOR flash chips, as documented on TN-13-07:
- Correcting Erase Suspend Hang Ups (page 20)
- Resolving the Delay After Resume Issue (page 22)
Paul Parsons [Wed, 7 Mar 2012 14:11:16 +0000 (14:11 +0000)]
mtd: chips: cfi_cmdset_0002: Match ENABLE_VPP()/DISABLE_VPP() calls
This patch is part of a set which fixes unnecessary flash erase and write errors
resulting from the MTD CFI driver turning off vpp while an erase is in progress.
This patch ensures that only those flash operations which call ENABLE_VPP() can
then call DISABLE_VPP(). Other operations should never call DISABLE_VPP().
Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Huang Shijie <b32955@freescale.com>
Ira W. Snyder [Fri, 6 Jan 2012 19:29:19 +0000 (11:29 -0800)]
mtd: cfi: AMD/Fujitsu compatibles: add panic write support
This allows the mtdoops driver to work on flash chips using the
AMD/Fujitsu compatible command set.
As the code comments note, the locks used throughout the normal code
paths in the driver are ignored, so that the chance of writing out the
kernel's last messages are maximized.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Huang Shijie <b32955@freescale.com>
ENGR00257947 mtd: use memcpy to replace the memcpy_fromio
During the read of NOR, the kernel actually calls the inline_map_copy_from()
to read the data out. And inline_map_copy_from() will use the memcpy_fromio()
to do the real job.
The memcpy_fromio macro maps _memcpy_fromio() in the current code.
But the _memcpy_fromio() will use readb() to do the copy work one byte
by one byte. This makes the read performance of NOR very slow(about 2~3MB/s).
A similiar discussion could be found in:
http://lists.infradead.org/pipermail/linux-arm-kernel/2009-November/003860.html
This patch replace the memcpy_fromio with memcpy which is optimized by the
kernel.
The following is the result from mtd_speedtest with M29W256GL7AN6E:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: not NAND flash, assume page size is 512 bytes.
mtd_speedtest: MTD device size 4194304, eraseblock size 131072, page size 512,
count of eraseblocks 32, pages per eraseblock 256, OOB size 0
mtd_speedtest: testing eraseblock write speed
mtd_speedtest: eraseblock write speed is 845 KiB/s
mtd_speedtest: testing eraseblock read speed
mtd_speedtest: eraseblock read speed is 19504 KiB/s
mtd_speedtest: testing page write speed
mtd_speedtest: page write speed is 845 KiB/s
mtd_speedtest: testing page read speed
mtd_speedtest: page read speed is 19140 KiB/s
mtd_speedtest: testing 2 page write speed
mtd_speedtest: 2 page write speed is 846 KiB/s
mtd_speedtest: testing 2 page read speed
mtd_speedtest: 2 page read speed is 19320 KiB/s
mtd_speedtest: Testing erase speed
mtd_speedtest: erase speed is 233 KiB/s
mtd_speedtest: Testing 2x multi-block erase speed
mtd_speedtest: 2x multi-block erase speed is 225 KiB/s
mtd_speedtest: Testing 4x multi-block erase speed
mtd_speedtest: 4x multi-block erase speed is 224 KiB/s
mtd_speedtest: Testing 8x multi-block erase speed
mtd_speedtest: 8x multi-block erase speed is 225 KiB/s
mtd_speedtest: Testing 16x multi-block erase speed
mtd_speedtest: 16x multi-block erase speed is 225 KiB/s
mtd_speedtest: Testing 32x multi-block erase speed
mtd_speedtest: 32x multi-block erase speed is 225 KiB/s
mtd_speedtest: Testing 64x multi-block erase speed
mtd_speedtest: 64x multi-block erase speed is 224 KiB/s
mtd_speedtest: finished
=================================================
Richard Zhu [Tue, 12 Mar 2013 08:35:42 +0000 (16:35 +0800)]
ENGR00257661 pcie: imx: pcie ep/rc validation
HW setup:
* Two i.MX6Q SD boards, one is used as PCIe RC, the other
is used as PCIe EP. Connected by 2*mini_PCIe to standard_PCIe
adaptors, 2*PEX cable adaptors, One PCIe cable.
SW setup:
* When build RC image, make sure that
CONFIG_IMX_PCIE=y
# CONFIG_IMX_PCIE_EP_MODE_IN_EP_RC_SYS is not set
CONFIG_IMX_PCIE_RC_MODE_IN_EP_RC_SYS=y
* When build EP image, make sure that
CONFIG_IMX_PCIE=y
CONFIG_IMX_PCIE_EP_MODE_IN_EP_RC_SYS=y
# CONFIG_IMX_PCIE_RC_MODE_IN_EP_RC_SYS is not set
Features:
* Set-up link between RC and EP by their stand-alone
125MHz running internally.
* In EP's system, EP can access the reserved ddr memory
(default address:0x40000000) of PCIe RC's system, by the
interconnection between PCIe EP and PCIe RC.
* add the configuration methods in the EP side, used to
configure the start address and the size of the reserved
RC's memory window.
- cat /sys/devices/platform/imx-pcie/rc_memw_info
- echo 0x41000000 > /sys/devices/platform/imx-pcie/rc_memw_start_set
- echo 0x800000 > /sys/devices/platform/imx-pcie/rc_memw_size_set
Throughput:
* when enable the EP_SELF_IO_TEST, and ARM core used as the
bus master: write speed ~300MB/s, read speed ~100MB/s.
* IPU used as the bus master: write speed ~344MB/s, read
speed ~211MB/s.
ENGR00256893-2 MX6Q/DL-Fix Ethernet performance issue when WAIT mode is active
All of the interrupts from the ENET block are not routed to
the GPC block. Hence ENET interrupts are not able to wake
up the SOC when the system is in WAIT mode. And the ENET
interrupt gets serviced only when another interrupt causes
the SOC to exit WAIT mode. This impacts the ENET performance.
To fix the issue two options:
1. Route the ENET interrupt to a GPIO. Need to enable the
CONFIG_MX6_ENET_IRQ_TO_GPIO in the config.
This patch provides support for routing the ENET interrupt
to GPIO_1_6. Routing to this GPIO requires no HW board mods.
If the GPIO_1_6 is being used for some other peripheral,
this patch can be followed to route the ENET interrupt to
any other GPIO though a HW mode maybe required.
2. If the GPIO mechanism cannot be used and is not enabled
by the above mentioned config, the patch will disable entry
to WAIT mode until ENET clock is active. When the ENET clock
is disabled, WAIT mode will be automatically enetered.
ENGR00256893-1 MX6Q/DL-Fix Ethernet performance issue when WAIT mode is active
All of the interrupts from the ENET block are not routed to
the GPC block. Hence ENET interrupts are not able to wake
up the SOC when the system is in WAIT mode. And the ENET
interrupt gets serviced only when another interrupt causes
the SOC to exit WAIT mode. This impacts the ENET performance.
To fix the issue two options:
1. Route the ENET interrupt to a GPIO. Need to enable the
CONFIG_MX6_ENET_IRQ_TO_GPIO in the config.
This patch provides support for routing the ENET interrupt
to GPIO_1_6. Routing to this GPIO requires no HW board mods.
If the GPIO_1_6 is being used for some other peripheral,
this patch can be followed to route the ENET interrupt to
any other GPIO though a HW mode maybe required.
2. If the GPIO mechanism cannot be used and is not enabled
by the above mentioned config, the patch will disable entry
to WAIT mode until ENET clock is active. When the ENET clock
is disabled, WAIT mode will be automatically enetered.
Jason Liu [Wed, 3 Apr 2013 05:45:39 +0000 (13:45 +0800)]
ENGR00255518 ipu/ipu3: using the kernel common help function div_u64
We don't need invent the wheel to implement the wrap for the _do_div,
we can use the kernel common helper function for the u64 divide with
div_u64() function call
This also fix the build break when CONFIG_DEBUG_SECTION_MISMATCH=y with
GCC4.6.3 cross-compile toolchain.
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `_do_div.part.1':
clkdev.c:(.text+0x15c23c): undefined reference to `__aeabi_uldivmod'
clkdev.c:(.text+0x15c25c): undefined reference to `__aeabi_uldivmod'
clkdev.c:(.text+0x15c2bc): undefined reference to `__aeabi_uldivmod'
clkdev.c:(.text+0x15c3ac): undefined reference to `__aeabi_uldivmod'
clkdev.c:(.text+0x15c3d0): undefined reference to `__aeabi_uldivmod'
This issue is caused by the wrongly optimized code produced by GCC,
See the bug report here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
The similar build break issue report at:
http://lists.infradead.org/pipermail/linux-mtd/2012-May/041677.html
ENGR00256933 ASoC: WM8962: Add delay after FLL-enable
There's a start-up time after FLL_ENA bit is set. While the driver didn't
run the delay code which already exists in the set_fll() function.
This patch let the driver run into the delay section, and made it work more
perfectly.
Previously, we didn't close FLL after playback/capture, which might cause
FLL work werid after a long time suspend.
This patch manually disables FLL after playback/capture.
Mark Brown [Fri, 27 Jan 2012 19:54:03 +0000 (19:54 +0000)]
ASoC: wm8962: Don't automatically enable and disable FLL
Only enable and disable the FLL when explicitly told to, supporting some
additional use cases and making the driver behaviour more standard.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Nicolin Chen <b42378@freescale.com>
(cherry picked from commit a968d9db3b3a9329587b09bd15f4981473c63a9d)
b02247 [Fri, 29 Mar 2013 06:09:43 +0000 (14:09 +0800)]
ENGR00255104 The opening time of cs42888 is very long, about 400ms
In this commit 957bc47ffbad8532f0e8f6463946e8c04bc3176f, add msleep(400)
for reducing noise in the hw_params, but this time is very long for opening
device.
In this patch, remove this time and use the "Soft Ramp on Zero Crossings" to
reduce the noise.
For both CSI_MEMx and CSI_PRP_VF(ENC)_MEM capture channels,
we disable them with the following sequence:
1) Wait for an idmac channel eof interrupt.
2) Disable CSI by clearing CSIx_EN in IPU_CONF register.
3) Disable idmac channel by clearing relevant bit in
IPU_IDMAC_CH_EN_1 register and other settings.
However, currently, we don't do 3) until CSI_PRP_VF(ENC)_MEM's
idmac channel being not busy by a while loop check. In case, an
external sensor is plugged out from the system or the sensor is
somehow broken, we will be unable to get out of that infinite
while loop. Since this check is unnecessary(we've already
waited for an idmac eof interrupt), this patch simply removes
it from the disable routine of CSI_PRP_VF(ENC)_MEM channel.
ENGR00256820-2 ASoC: imx-wm8962: Fix incorrect setting of wm8962's FLL source
WM8962's internal FLL is sourced from MCLK on SabreSD, while the machine
driver set its source to OSC, which's definitely wrong.
So This patch changed its source to MCLK to prevent some potential issue.
Acked-by: Wang Shengjiu <b02247@freescale.com> Signed-off-by: Nicolin Chen <b42378@freescale.com>
ENGR00256820-1 ASoC: WM8962: revert FLL-disable before FLL-setting
The patch at the commit 30293bc6 dropped FLL-disabling code from wm8962
driver, which was a work around for CR 00209905. Since we fixed the issue in
a better way(commit 018958f4), we don't need the work around any more.
And in wm8962's datasheet, Wolfson suggests that driver should disable and
re-enable the FLL after the other registers're updated. So it's better for us
to revert the code to prevent some potential issue.
Acked-by: Wang Shengjiu <b02247@freescale.com> Signed-off-by: Nicolin Chen <b42378@freescale.com>
There is annoying ipu warning when doing preview
by using v4l2 fg overlay component:
/unit_tests/mxc_v4l2_overlay.out -iw 320 -ih 240 -ow 1280
-oh 720 -r 0 -fg -t 5
imx-ipuv3 imx-ipuv3.0: IDMAC12's EBA0 is not 8-byte aligned
This warning can be seen only when preview size is bigger
than 1024*1024(ipu device driver split mode is enabled).
After debug, it appears that the unaligned buffer address
is caused by input cropping for left strip, and this
cropping is triggered by the split mode algrithm. The
algrithm is complex, so currently this patch only changes
the input pixel format of the ipu task from UYVY to NV12
to workaround this warning.
Wayne Zou [Mon, 25 Mar 2013 04:56:46 +0000 (12:56 +0800)]
ENGR00256629 V4L2 output: Fix color bar issue on 1080p HDMI display
When doing video playback on video16, which is also the first framebuffer
and used for fb console as well, there is a color bar on top of 1080p screen.
We need to make sure the correct vmode when doing pan display.
Liu Ying [Mon, 25 Mar 2013 03:32:36 +0000 (11:32 +0800)]
ENGR00253652 ov5640 dvp:Align iq setting with mipi camera
According to the OV FAE, the image quality(iq) setting is
from 0x5000 register to 0x3a1f register in the camera's
initialization setting. This patch aligns image quality
setting of ov5640 dvp camera to ov5640 mipi camera.
The registers whose values are changed are 0x5001, 0x5189,
0x518b, 0x518d, 0x518e, 0x518f, 0x5199, 0x519c and 0x519d.
This change may improve the image quality of 5M/1M/VGA/QVGA
taken pictures in Android according to test team observation.
Fugang Duan [Wed, 27 Mar 2013 10:23:16 +0000 (18:23 +0800)]
ENGR00255406 net: fec: Workaround tx hang due to TDAR bit cleared by uDMA
MTIP enet IP have one IC issue recorded at PDM ticket:TKT168103
The issue description:
The TDAR bit after being set by software is not acted upon by the ENET
module due to the timing of when the ENET state machine clearing the
TDAR bit occurring coincident or momentarily after the software sets
the bit.
The result:
The corresponding transmit packet for an incoming ping is delayed.
Workaround:
This forces the ENET module to check the Transmit buffer descriptor
and take action if the “ready” flag is set. Otherwise the ENET module
returns to idle mode.
Loren Huang [Thu, 28 Mar 2013 10:14:17 +0000 (18:14 +0800)]
ENGR00255322 Disable non-contiguous memory using for VG
Current OpenVG doesn't support to use non-contiguous memory.
Forbid VG to try to allocate non-contiguous memory when video
memory is used up temporarily.
Robin Gong [Mon, 25 Mar 2013 06:27:42 +0000 (14:27 +0800)]
ENGR00255111 battery: fix voltage decreased only while discharging
If system run higher cpu loading with bigger current, such as GPU or VPU,
the voltage of battery will decrease down quickly and rise up later.But the
battery driver only permit voltage decreasing while discharging before, in
other words, in the above case , the voltage will keep in very low level,
although the voltage will rise back again.
Now, remove the constrain in the code. Of course, with the patch, voltage will
down and rise back when run high loading user case, but it's better than
LOW ALWAYS, in worst case, the battery capacity will be 0 as test team reported
Please note :
Current battery capaity is not accurate because of hardware
design defect(ENGR00219632) on Sabresd.So please ignore the accuracy issue.
Peter Chen [Fri, 22 Mar 2013 05:16:22 +0000 (13:16 +0800)]
ENGR00255484-2 usb: ehci-arc: add NULL pointer check for pdata->pdev
The pdata->pdev is initialized at platform code, if init
fails at first, it will be not initialized, and platform exit
will not be called. This also fixes an oop when config usb
module wrongly:
Nicolin Chen [Fri, 22 Mar 2013 02:57:07 +0000 (10:57 +0800)]
ENGR00255482 ASoC: HDMI-audio: Add error message for HDMI-video detect failure
HDMI-audio depends on HDMI-video. If users want to use HDMI-audio function,
they need to load HDMI-video first. Sometime users would forget to put video
info into U-boot cmdline, "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24" for
example. That might cause HDMI-auido driver fail to detect HDMI-video.
Previously, if this happened to system, driver only returned with "ENOMEM"
and system would print "Can't allocate memory". This might confuse users due
to the vague infomation. Users would be hard to figure out the root cause.
So this patch just add some error message to give users a clear indication,
and changed the "ENOMEM" error number to the more precise "ENODEV".
Acked-by: Wang Shengjiu <b02247@freescale.com> Signed-off-by: Nicolin Chen <b42378@freescale.com>
Robby Cai [Thu, 14 Mar 2013 08:51:00 +0000 (16:51 +0800)]
ENGR00252064-2 mx6sl: ov5640: need enable MCLK before read sensor ID
After the patch of auto-detection for sensor pushed, there's a need to
read sensor ID in probe function. But on MX6SL, MCLK is not enabled at
that time. So need to enable it before read sensor ID.
Robby Cai [Thu, 14 Mar 2013 08:37:09 +0000 (16:37 +0800)]
ENGR00252064-1 csi/v4l: need power on sensor for its initialization
Need power on the sensor for its initialization, otherwise the sensor can
not work properly.
Signed-off-by: Sheng Nan <b38800@freescale.com> Signed-off-by: Robby Cai <R63905@freescale.com>
(cherry picked from commit 24ef6f52c717b9f2288d1c66ec6efd284935e23e)
Robby Cai [Tue, 12 Mar 2013 06:59:49 +0000 (14:59 +0800)]
ENGR00253849 EPDC: fix build warnings in epdc fb driver
This patch is to fix the following warnings:
drivers/video/mxc/mxc_epdc_fb.c:5062:2: warning: initialization from
incompatible pointer type [enabled by default]
drivers/video/mxc/mxc_epdc_fb.c:5062:2: warning: (near initialization for
'mxc_epdc_fb_driver.shutdown') [enabled by default]
* Correct mipi-csi2 settings only one data line is used
* Add mx6q_mipi_csi1_io_init ipu-csi setting callback
use virtual channel 1 and attach it to CSI1 -> IPU0
* Set i2c slave address to 0x52
* Set ipu-csi clko_clk
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Wayne Zou [Tue, 19 Mar 2013 01:38:04 +0000 (09:38 +0800)]
ENGR00254931 IPUv3 Fb: Fix display twinkling issue during suspend/resume
Fix display twinkling issue when video playback on LVDS during suspend/resume.
The issue happens when the rootfs application Xfbdev calls fb_set_var() for IPU
BG fb to unblank the console, so it wants to reinitialize the IPU BG. However,
IPU FG is still being used for video playback.It is reasonable to refuse
reprogramme because of the resources confilct.
Robin Gong [Fri, 15 Mar 2013 04:37:04 +0000 (12:37 +0800)]
ENGR00254457 mx6dl: fix mx6dl TO1.1 can't enter 'mem'
The previous patch ENGR00251630 didn't notice mx6q_revision() will
return -EINVAL and will match 'mx6q_revision()<IMX_CHIP_REVISION_1_1'
,then mx6dl TO1.1 will also change suspend state to 'standby'.
Robin Gong [Thu, 14 Mar 2013 09:19:44 +0000 (17:19 +0800)]
ENGR00254267 MX6DL/MX6SL max freq: Fix max cpu freq at 1G on MX6DL ARD
For MX6DL,align max cpufreq judge by SPEED_GRADING fuse bit with MX6DQ.
For MX6SL without the fuse bit, we need add condition check, if found
arm_max_freq set by default , change to1G. Else decided by 'arm_freq'
setting by cmdline.
Wayne Zou [Tue, 12 Mar 2013 08:54:59 +0000 (16:54 +0800)]
ENGR00253927 IPU: Fix NULL pointer bug when BG EOF interrupt occur early
Fix NULL pointer bug when IPU BG EOF interrupt occur before register irq handler
It can be reproduced on MIPI DSI display on i.mx6dl SabreSD board.
The sequence is:
a) enable display channel
b) pan display (fb_set_var()) -> ipu_enable_irq
c) ipu_request_irq
If an EOF interrupt comes before c and after b, the issue happens.