As there is only one IPU embedded in MX6DL and two IPUs embedded
in MX6DQ. The max ipuv3 fb platform driver number is two for
MX6DL and four for MX6DQ.
Liu Ying [Wed, 12 Sep 2012 01:43:12 +0000 (09:43 +0800)]
ENGR00223797-6 MX6 SabreSD:Initialize late init for IPUv3 fb pdata
This patch initializes late init field to false for IPUv3 fb pdata,
so we don't support late init by default unless we change them to
true in other places specificly.
Liu Ying [Wed, 12 Sep 2012 01:36:12 +0000 (09:36 +0800)]
ENGR00223797-5 MX6 SabreSD:Initialize bypass reset for IPUv3 pdata
This patch initializes bypass reset field to false for IPUv3 pdata,
so we don't support bypass reset by default unless we change them
to true in other places specificly.
Liu Ying [Tue, 11 Sep 2012 10:10:11 +0000 (18:10 +0800)]
ENGR00223797-4 IPUv3 fb:Support framebuffer late init
This patch adds late init support in IPUv3 fb driver
to avoid IPUv3 fb being re-initialized during probe if
a platform supports smooth transition from bootloader
splashimage to system UI. The re-initialization will
be delayed to the first time the user triggers
mxcfb_set_par() and unblank the framebuffer.
The following items are done to support this:
1) Move global alpha and color key setting in probe
after framebuffer is registered(before registering
we enable IPU hsp clock), because the 2 APIs enable
and disable IPU hsp clock which may cause IPU stops
running in ipuv3 fb probe function.
2) Do not clear framebuffer content in probe function
if late init is set. This is to avoid bootloader
splashimage content is cleared.
3) If late init is set, do not re-initialize and
unblank framebuffer in probe function, but initialize
and enable ipu display channel instead to enable
the ipu hsp clock. Refer to the code comment for
detail.
4) Delay register IPU interrupts used by framebuffer
until IPU hsp clock is enabled by 3). As the APIs
to register IPU interrupts may enable and disable
IPU hsp clock as well.
Liu Ying [Tue, 11 Sep 2012 10:20:39 +0000 (18:20 +0800)]
ENGR00223797-3 ARM:IPUv3 fb:Add late init in pdata
This patch adds late init field support in ipuv3 fb
platform data, so that a platform may choose to not
to initialize framebuffer until the user triggers
set_par(), which may support smooth transition from
bootloader splashimage to system UI.
Liu Ying [Tue, 11 Sep 2012 10:18:39 +0000 (18:18 +0800)]
ENGR00223797-2 IPUv3:Support bypass reset for probe
This patch adds bypass reset support in IPUv3 driver
probe function to avoid IPUv3 being reset if a plat-
form supports smooth transition from bootloader
splashimage to system UI.
Liu Ying [Tue, 11 Sep 2012 10:16:12 +0000 (18:16 +0800)]
ENGR00223797-1 ARM:IPUv3:Add bypass reset in pdata
This patch adds bypass reset field support in ipuv3
platform data, so that a platform may choose not to
reset ipuv3 when doing probe, which may support
smooth transition from bootloader splashimage to
system UI.
Wayne Zou [Thu, 30 Aug 2012 09:20:06 +0000 (17:20 +0800)]
ENGR00220747 V4L2 out: Fix mosaic and flash issue if use VDOA input crop mode
Fix bug:
A lot of mosaic and flash issue if use VDOA mode when doing video playback
on stream H264_BP13_fc_320x136_29.97_444_AAC_48_130_2_vbr.mp4.
For this special stream, the frame size is 320x144 and the stream includes
input cropping information:320x136. It needs to use 320x144 frame size to
do tiled format conversion instead of 320x128 after alignment.
Arve Hjønnevåg [Thu, 24 Feb 2011 00:51:58 +0000 (16:51 -0800)]
ARM: etm: Power down etm(s) when tracing is not enabled
Without this change a saw an 18% increase in idle power consumption
on one deivce when trace support is compiled into the kernel. Now
I see the same increase only when tracing.
Arve Hjønnevåg [Sat, 5 Feb 2011 06:38:14 +0000 (22:38 -0800)]
ARM: etm: Support multiple ETMs/PTMs.
If more than one ETM or PTM are present, configure all of them
and enable the formatter in the ETB. This allows tracing on dual
core systems (e.g. omap4).
Arve Hjønnevåg [Sat, 5 Feb 2011 06:38:14 +0000 (22:38 -0800)]
ARM: etm: Return the entire trace buffer if it is empty after reset
On some SOCs the read and write pointer are reset when the chip
resets, but the trace buffer content is preserved. If the status
bits indicates that the buffer is empty and we have never started
tracing, assume the buffer is full instead. This can be useful
if the system rebooted from a watchdog reset.
Arve Hjønnevåg [Tue, 1 Feb 2011 02:33:55 +0000 (18:33 -0800)]
ARM: etm: Configure data tracing
The old code enabled data tracing, but did not configure the
range. We now configure it to trace all data addresses by default,
and add a trace_data_range attribute to change the range or disable
data tracing.
Arve Hjønnevåg [Sat, 29 Jan 2011 07:44:43 +0000 (23:44 -0800)]
ARM: etm: Allow range selection
Trace kernel text segment by default as before, allow tracing of other
ranges by writing a range to /sys/devices/etm/trace_range, or to trace
everything by writing 0 0.
Arve Hjønnevåg [Tue, 1 Feb 2011 05:34:47 +0000 (21:34 -0800)]
ARM: etm: Don't try to clear the buffer full status after reading the buffer
If the write address was at the end of the buffer, toggling the trace
capture bit would set the RAM-full status instead of clearing it, and
if any of the stop bits in the formatter is set toggling the trace
capture bit may not do anything.
Instead use the read position to find out if the data has already
been returned.
This also fixes the read function so it works when the trace buffer is
larger than the buffer passed in from user space. The old version
would reset the trace buffer pointers after every read, so the second
call to read would always return 0.
make shi [Thu, 20 Sep 2012 09:20:14 +0000 (17:20 +0800)]
ENGR00225131-06 MX6 PM: clear stop_mode_config after system resume
- If stop_mode_config is set as 1, the USB otg vbus wakeup system can be
supported
- After system resume, need clear stop_mode_config bit to keep the 1P1
default off
make shi [Thu, 20 Sep 2012 09:15:26 +0000 (17:15 +0800)]
ENGR00225131-05 MX6 USB: set stop_mode_config bit if wake up is enabled
IC designer had clarified that 1P1 can be turned off if we do not need support
remote wakeup. So If there is no requirement for USB remote wake up, the 1P1
can be turn off. USB driver will support dynamically turn on(off) 1P1 during
system suspend. 1P1 will be turn on depend on USB wakeup is enabled.
- Set stop_mode_config bit if USB host need support USB remote wake up
- Set stop_mode_config bit if USB device need support USB DP/DM wake
up system
make shi [Thu, 20 Sep 2012 09:12:47 +0000 (17:12 +0800)]
ENGR00225131-04 MX6 USB: implement platform_phy_power_on for USB otg and h1
IC designer had clarified that 1P1 can be turned off if we do not need support
remote wakeup. So If there is no requirement for USB remote wake up, the 1P1
can be turn off. USB driver will support dynamically turn on(off) 1P1 during
system suspend. 1P1 will be turn on depend on USB wakeup is enabled.
Set stop_mode_config bit to turn on 1P1 during system suspend to support USB
host remote wake up or USB device DP/DM wake up.
make shi [Thu, 20 Sep 2012 09:10:20 +0000 (17:10 +0800)]
ENGR00225131-03 MX6 USB: add platform_phy_power_on platform data in head file
IC designer had clarified that 1P1 can be turned off if we do not need support
remote wakeup. So If there is no requirement for USB remote wake up, the 1P1
can be turn off. USB driver will support dynamically turn on(off) 1P1 during
system suspend. 1P1 will be turn on depend on USB wakeup is enabled.
make shi [Thu, 20 Sep 2012 07:14:58 +0000 (15:14 +0800)]
ENGR00225131-02 USB: revert ENGR00221317-02 stop_mode_config patch head file
IC designer had clarified that 1P1 can be turned off if we do not need support
remote wakeup. So If there is no requirement for USB remote wake up, the 1P1
can be turn off. USB driver will support dynamically turn on(off) 1P1 during
system suspend. 1P1 will be turn on depend on USB wakeup is enabled.
make shi [Thu, 20 Sep 2012 07:11:46 +0000 (15:11 +0800)]
ENGR00225131-01 USB: revert ENGR00221317-02 about set stop_mode_config patch
IC designer had clarified that 1P1 can be turned off if we do not need support
remote wakeup. So If there is no requirement for USB remote wake up, the 1P1
can be turn off. USB driver will support dynamically turn on(off) 1P1 during
system suspend. 1P1 will be turn on depend on USB wakeup is enabled.
Ryan QIAN [Mon, 24 Sep 2012 07:25:36 +0000 (15:25 +0800)]
ENGR00225594 mmc: sdhci: remove calling enable clk in interrupt context
There's kernel warning without when insmod WiFi module as follows:
------------[ cut here ]------------
WARNING: at kernel/irq/handle.c:130 handle_irq_event_percpu+0x164/0x180()
irq 55 handler sdhci_irq+0x0/0x988 enabled interrupts
Modules linked in: ar6000
[<800471dc>] (unwind_backtrace+0x0/0xfc) from
[<80072fd0>] (warn_slowpath_common+0x4c/0x64)
[<80072fd0>] (warn_slowpath_common+0x4c/0x64) from
[<8007307c>] (warn_slowpath_fmt+0x30/0x40)
[<8007307c>] (warn_slowpath_fmt+0x30/0x40) from
[<800a9f54>] (handle_irq_event_percpu+0x164/0x180)
[<800a9f54>] (handle_irq_event_percpu+0x164/0x180) from
[<800a9fac>] (handle_irq_event+0x3c/0x5c)
[<800a9fac>] (handle_irq_event+0x3c/0x5c) from
[<800ac2a8>] (handle_fasteoi_irq+0x98/0x148)
[<800ac2a8>] (handle_fasteoi_irq+0x98/0x148) from
[<800a9a2c>] (generic_handle_irq+0x2c/0x38)
[<800a9a2c>] (generic_handle_irq+0x2c/0x38) from
[<80041f60>] (handle_IRQ+0x4c/0xb8)
[<80041f60>] (handle_IRQ+0x4c/0xb8) from
[<80040f8c>] (__irq_svc+0x4c/0xe8)
[<80040f8c>] (__irq_svc+0x4c/0xe8) from
[<800420e4>] (default_idle+0x24/0x28)
[<800420e4>] (default_idle+0x24/0x28) from
[<80042730>] (cpu_idle+0xbc/0xfc)
[<80042730>] (cpu_idle+0xbc/0xfc) from
[<80008904>] (start_kernel+0x248/0x288)
[<80008904>] (start_kernel+0x248/0x288) from
[<10008040>] (0x10008040)
---[ end trace 95ab51b95e0e8e5f ]---
it is caused by calling cancel_delayed_work_sync in sdhci_enable_clk, since
it will call spin_unlock_irq which will possibly enable irq in interrupt
context. if sdhci_enable_clk is called in interrupt context this warning
will be shown.
sdhci_enable_clk will be called in interrupt context in the following path:
sdhci_irq->mmc_signal_sdio_irq->mmc_signal_sdio_irq->sdhci_enable_sdio_irq->...
|____________________interrupt context____________________________________
fix:
Remove calling sdhci_enable_clk in sdhci_enable_sdio_irq. For sdio cards, sdhci
clk will not be disabled, so it is save to remove it.
Signed-off-by: Ryan QIAN <b32804@freescale.com> Acked-by: Dong Aisheng <b29396@freescale.com>
ENGR00225534-2 mmc: sdhci: using cancel_work_sync instread of cancel_delayed_work
We recently met an rarely happened sychronization issue which can cause
mmc timeout during transfer as follows:
[ OK ]onfiguring network interfaces...
[ OK ]ctivating swap...
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 sending status command, retrying
mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0xd00
mmcblk0: error -110 transferring data, sector 9981952, nr 16, cmd response 0x900, card status 0xc00
end_request: I/O error, dev mmcblk0, sector 9981952
The root cause is that host uses cancel_delayed_work to cancel the delayed
clock disable work to avoid clock to be disabled if a new cmd
transfer request happens.
However, the work callback may already be running during the excution
of cancel_delayed_work which can not be cancelled and causes
the clock probably still to be disabled during cmd transfer,
then cmd timeout happens.
Using cancel_work_sync instead to wait for the completion of clock disable
first then we can make sure the clock can not be disabled during the cmd
transfer.
BTW, although the original code checks if in interrupt context, however,
it's still not interrupt context safe due to the unsafe platform_clk_ctrl,
so it's ok to directly use cancel_work_sync here and sdhci_enable_clk is
simply not allowed to be called in irq context.
Acked-by: Ryan QIAN <b32804@freescale.com> Signed-off-by: Dong Aisheng <b29396@freescale.com>
Adrian Hunter [Fri, 21 Sep 2012 10:28:42 +0000 (18:28 +0800)]
ENGR00225534-1 mmc: core: move ->request() call from atomic context
mmc_request_done() is sometimes called from interrupt or other atomic
context. Mostly all mmc_request_done() does is complete(), however it
contains code to retry on error, which uses ->request(). As the error
path is certainly not performance critical, this may be moved to the
waiting function mmc_wait_for_req_done().
This allows ->request() to use runtime PM get_sync() and guarantee it
is never in an atomic context.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Ulf Hansson <ulf.hansson@stericsson.com> Signed-off-by: Chris Ball <cjb@laptop.org> Acked-by: Ryan QIAN <b32804@freescale.com> Signed-off-by: Dong Aisheng <b29396@freescale.com>
Robby Cai [Wed, 12 Sep 2012 06:32:34 +0000 (14:32 +0800)]
ENGR00224476 pgc: fix display power gating causes PxP processing timeout
The root-cause is PxP need the clock to be on for synchronous reset.
This patch turned on PXP axi clock, and EPDC/LCDIF pix clock, and
EPDC/LCDIF axi clock before power up. The driver codes can guarantee
the clock setting be restored to the one before suspend.
ENGR00223533 - FEC : fix net watchdog timeout due not refreshing TX timers
When do overnight gpu stress test throught nfs, kernel dump as below:
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x284/0x2a8()
NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed out
Modules linked in: galcore imx2_wd_test [last unloaded: galcore]
[<80045854>] (unwind_backtrace+0x0/0xf8) from [<80070c2c>]
(warn_slowpath_common+0x4c/0x64)
<snip>
In sometime, ethernet cannot recover after watchdog timeout which
results in nfs no responding and system hang on.
The patch fixes the way that ->trans_start is refreshed to avoid watchdog
timeout during ethernet status change (such as speed, duplex), and re-init
fec to recover ethernet after watchdog timeout.
Users may call FBIOPUT_VSCREENINFO framebuffer ioctrl to set
a framebuffer's pixel format by specifying bits_per_pixel field
and red/green/blue/transp fields of struct fb_var_screeninfo.
Users may also know a framebuffer's pixel format at which it is
working by calling FBIOGET_VSCREENINFO framebuffer ioctrl, red/
green/blue/transp bitfields of struct fb_var_screeninfo tell the
exact offset and length of each color component in a pixel. This
patch supports RGB24/RGB32/ABGR32 pixel formats with these 2 ioctrls.
To change the default pixel format when initializeing a framebuffer
at the first time, users may add 'fbpix=' option in framebuffer
kernel command line option, for example, 'video=mxcfb0:fbpix=ABGR32'
makes fb0's default pixel format be ABGR32. 'bpp=' option cannot
overwrite 'fbpix=' option, for example, 'video=mxfb0:fbpix=RGB24,
bpp=16' still makes fb0 work at RGB24 by default. To be back
compatible, this patch doesn't change the default pixel formats
(BGR24/BGR32/RGB565) for each bits_per_pixel, if users don't
provide valid 'fbpix=' option.
Liu Ying [Wed, 19 Sep 2012 02:26:25 +0000 (10:26 +0800)]
ENGR00224910 IPUv3 fb:Correct logic to check BGR24 for if= option
This patch corrects the logic to check BGR24 pixel format for
'if=' option in kernel bootup command line of framebuffer.
After applying the patch, users may use 'if=BGR24' to specify
the display data format to be BGR24. For example, 'video=mxcfb0:
dev=lcd,LCD_VIDEO_NAME,if=BGR24' makes IPUv3 output BGR24 data
to fb0's lcd panel.
Daiyu Ko [Wed, 19 Sep 2012 16:15:43 +0000 (11:15 -0500)]
ENGR00221594 Add Dithering algorism support into EPDC driver
Adding Atkinson's dithering alorism implementation into our EPDC
Driver with Y8->Y1 and Y8->Y4 supported. Two EPDC flags have been
added to support the features. EPDC_FLAG_USE_DITHERING_Y1 and
EPDC_FLAG_USE_DITHERING_Y4.
ENGR00224938 HDMI audio: clear HDMI dma done bit before start
HDMI hardware fix: signal of HDMI DMA DONE is hard connected to SDMA
event line. SDMA event is triggered by edge. If the HDMI DMA done is
already 1 before start, there would be no SDMA event being trigged after
HDMI generates another HDMI DONE signal.
In this patch, clear HDMI DONE bit before start HDMI audio DMA.
Adrian Alonso [Thu, 13 Sep 2012 21:43:10 +0000 (16:43 -0500)]
ENGR00224886 board-mx6q-sabreauto: remove camera control lines
* Remove camera control lines, this gpio control lines are used by
other periherals
* GPIO_4_5 correspond to RGMII_INT
* GPIO_3_24 correspond to CSI0_DAT5 parallel tv-in
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Adrian Alonso [Thu, 13 Sep 2012 16:26:56 +0000 (11:26 -0500)]
ENGR00224275-2 board-mx6q-sabreauto: remove unsupported ov5640 camera
* Remove unsupported camera device ov5640, there is no
hardware module available for sabreauto target board.
No mechanical connector compability with existing capture
sensor.
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Adrian Alonso [Tue, 11 Sep 2012 23:25:42 +0000 (18:25 -0500)]
ENGR00224275-1 board-mx6q-sabreauto: remove unsupported ov3640 camera
* Remove unsupported camera device ov3640, there is no
hardware module available for sabreauto target board.
* No mechanical connector compability with existing capture
sensors.
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Josh Boyer [Thu, 18 Aug 2011 11:37:21 +0000 (07:37 -0400)]
perf tools: Fix build against newer glibc
Upstream glibc commit 295e904 added a definition for __attribute_const__
to cdefs.h. This causes the following error when building perf:
util/include/linux/compiler.h:8:0: error: "__attribute_const__"
redefined [-Werror] /usr/include/sys/cdefs.h:226:0: note: this is the
location of the previous definition
Wrap __attribute_const__ in #ifndef as we do for __always_inline.
Robin Gong [Thu, 13 Sep 2012 06:19:41 +0000 (14:19 +0800)]
ENGR00224137 mx6 : restore VDD_PU in resume with the old value before suspend
Before, VDD_PU regulator will be set 1.1V for ever, but now VDD_PU track with
VDD_ARM, so we can not restore with 1.1V when system resume back.We need save
the old value set when power off PU in suspend flow, and then restore it in
resume flow. Signed-off-by: Robin Gong <B38343@freescale.com>
ENGR00224245 HDMI AUDIO: stop/start PCM while unplug,blank/plug, unblank
When unplug, blank happens, HDMI audio can't play properly. So in
driver, audio pcm would be disconnected when event above happens.
However, pulse audio can't process disconnect event properly and if an
blank or unplug event happens, HDMI sink would lost and can't be back
again.
In this patch, instead of disconnecting audio PCM stream, triggering
stop audio pcm while unplug and blank, triggering start again while plug
and unblank if the audio pcm is triggerd stop in the unplug/blank event. Signed-off-by: Chen Liangjun <b36089@freescale.com>
ENGR00223349-1 gpmi: add a new field for HW_GPMI_TIMING1
The gpmi_nfc_compute_hardware_timing{} should contains all the
fields setting for gpmi timing registers. It already contains the fields
for HW_GPMI_TIMING0 and HW_GPMI_CTRL1.
So it is better to add a new field setting for HW_GPMI_TIMING1 in
this data structure. This makes the code more clear in logic.
This patch also changs some comments to make the code more readable.
ENGR00223816 HDMI AUDIO: fix kernel panic cause by accessing unavailable memory
HDMI audio driver is responsible for add IEC header into audio sample.
In HDMI audio driver, a variable named rtd->appl_bytes is maintained to
stand for how many audio sample have already processed. appl_bytes
stands for how many audio sample the user space have already feed into
kernel driver. So we use the connt = appl_bytes - rtd->appl_bytes to
decide how many data need to be processed. And the processed data would
be write into an preallocated buffer called hw_buf in driver.
When doing seek operation, the appl_bytes changes in an wide range. So
it is possible that the count value is far larger than the size of
hw_buf and the memory access un-existed address error would happens.
In this patch, Add check operation for count to avoid kernel panic.
After doing some suspend/resuem test, secondary cores BogoMIPs
will be wrong, the root cause is that when cpufreq is changed,
we only update the online cpus' loops_per_jiffy, and when secondary
cores back to online, we skip the loops_per_jiffy calibration. During
suspend/resume, the cpufreq can be changed during disabling/enabling
secondary cores, which will make secondary cores loops_per_jiffy
wrong, so here we need to update all possible cpus' loops_per_jiffy
when cpufreq is changed.
ENGR00221671 - i2c :imx : fix some i2c devices can not suspend
i2c device (isl29023) can not suspend once during hdmi
audio suspend/resume test, and print log:
pm_op(): i2c_device_pm_suspend+0x0/0x38 returns -4 PM: Device
2-0044 failed to suspend: error -4 PM: Some devices failed to
suspend PM: resume of devices complete after 40.936 msecs
Restarting tasks ... done.
Because suspend function in isl29023 driver requires i2c bus
to write isl29023 device. I2C apdater driver process any signal
as exception during waiting the bus idle, so once user space sent
out signal during suspend, I2C device cannot request bus.
Using "fatal_signal_pending()" instead of "signal_pending()"
to avoid the waiting of bus idle to be terminated by general
signals except SIGKILL. After the change, i2c adapter can be
terminated by kill signal from user space with "CTRL+C" or
kill command operation.
Ethernet performance is downgraded when wait mode on in
100Mbps mode.
wait mode off:
100Mbps mode: tx bandwidth is 94Mbps
rx bandwidth is 94Mbps
wait mode on:
100Mbps mode: tx bandwidth is 30Mbps
rx bandwidth is 94Mbps
After apply the patch:
wait mode on:
100Mbps mode: tx bandwidth is 94Mbps
rx bandwidth is 94Mbps
Wait mode on cause enet interrupt has long latency, which
results in BD entries are full and stop tx queue, so cpus
have more chance to enter wait mode.
Incresing TX BD entries can properly accommodate the blance
between BD request before tx packets and BD release after tx
completion in interrupt process.
Sascha Hauer [Tue, 26 Jun 2012 15:26:16 +0000 (17:26 +0200)]
mtd: gpmi-nand: fix read page when reading to vmalloced area
The gpmi-nand driver uses virt_addr_valid() to check whether a buffer
is suitable for dma. If it's not, a driver allocated buffer is used
instead. Then after a page read the driver allocated buffer must be
copied to the user supplied buffer. This does not happen since commit 7725cc85932bd02dd12c23108e0ef748c551ccba.
This patch fixes the issue. The bug is encountered with UBI which uses a
vmalloced buffer for the volume table.
We now have an interface for notifying the nand_ecc_ctrl functions when OOB
data must be returned to the upper layers and when it may be left untouched.
This patch fills in the 'oob_required' parameter properly from
nand_do_{read,write}_ops. When utilized properly in the lower layers, this
parameter can improve performance and/or reduce complexity for NAND HW and SW
that can simply avoid transferring the OOB data.
Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Acked-by: Jiandong Zheng <jdzheng@broadcom.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
mtd: nand: add 'oob_required' argument to NAND {read,write}_page interfaces
New NAND controllers can perform read/write via HW engines which don't expose
OOB data in their DMA mode. To reflect this, we should rework the nand_chip /
nand_ecc_ctrl interfaces that assume that drivers will always read/write OOB
data in the nand_chip.oob_poi buffer. A better interface includes a boolean
argument that explicitly tells the callee when OOB data is requested by the
calling layer (for reading/writing to/from nand_chip.oob_poi).
This patch adds the 'oob_required' parameter to each relevant {read,write}_page
interface; all 'oob_required' parameters are left unused for now. The next
patch will set the parameter properly in the nand_base.c callers, and follow-up
patches will make use of 'oob_required' in some of the callee functions.
Note that currently, there is no harm in ignoring the 'oob_required' parameter
and *always* utilizing nand_chip.oob_poi, but there can be
performance/complexity/design benefits from avoiding filling oob_poi in the
common case. I will try to implement this for some drivers which can be ported
easily.
Note: I couldn't compile-test all of these easily, as some had ARCH
dependencies.
[Huang Shijie: I remove the unused code for the other drivers.]
[dwmw2: Merge later 1/0 vs. true/false cleanup] Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Acked-by: Jiandong Zheng <jdzheng@broadcom.com> Acked-by: Mike Dunn <mikedunn@newsguy.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>
If GPU2D used PLL3 as root, we need enable PLL
during GPU power up flow so that we can power up
GPU2D properly.
Till now, this issue can only be duplicated on
Android.
BUILD WARNING:
WARNING: arch/arm/mach-mx6/built-in.o(.data+0x7e44): Section mismatch in
reference from the variable sab_audio_data to the (unknown reference)
.init.rodata:(unknown) The variable sab_audio_data references the
(unknown reference) __initconst (unknown) If the reference is valid then
annotate the variable with __init* or __refdata (see linux/init.h) or
name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
In this patch, remove esai_p2p struct with init attribute.
Fix HDMI build warning.
drivers/video/mxc_hdmi.c: In function 'mxc_hdmi_set_mode':
drivers/video/mxc_hdmi.c:1659: warning: assignment discards
qualifiers from pointer target type
drivers/video/mxc_hdmi.c: At top level:
driver/video/mxc_hdmi.c:1398: warning: 'mxc_hdmi_enable_pins'
defined but not used
Remove unused function mxc_hdmi_enable_pins() and mxc_hdmi_disable_pins()
from code. Fix defined but unused function build warning.
Added pointer conversion from const poniter to non-const pointer.
Rong Dian [Mon, 3 Sep 2012 10:37:43 +0000 (18:37 +0800)]
ENGR00222078 power battery:fix charger attach detect missing after resume
1.config gpio dok for AC charger as wake up irq, config gpio uok
for USB charger as wake up irq.
2.add AC/USB charger detect in resume,fix charger detect status update
missing after attach AC/USB charger and resume system
arch/arm/mach-mx6/irq.c: In function 'mx6_init_irq':
arch/arm/mach-mx6/irq.c:106: warning: unused variable 'reg'
arch/arm/mach-mx6/clock_mx6sl.c:1807:
warning: function declaration isn't a prototype
arch/arm/mach-mx6/clock_mx6sl.c:1535:
warning: 'tzasc1_clk' defined but not used
arch/arm/mach-mx6/clock_mx6sl.c:1576:
warning: 'mx6per2_clk' defined but not used
arch/arm/mach-mx6/clock_mx6sl.c:1708:
warning: 'ocram_clk' defined but not used
ENGR00221854 HDMI: suspend/resume hdmi_phy fail to lock.
HDMI PHY init function will been called four times during system resume.
The first call before pixel clock enable, so it will print
PHY PLL unlock message, but the PHY PLL will locked in the next
three times called. It will not affect HDMI PHY function.
ENGR00222900 HDMI AUDIO: fix kernel panic when doing suspend-resume test
In MX6 series, HDMI audio driver is responsible for add IEC header to
audio samples. Driver would maintain variables to cover this work.
The old driver would cause memory access exceeding issue:
1. Resume from an playback. In this case, variable maintained by ALSA is
updated while variable maintained by HDMI driver is not updated. The
mmap copy operation would run into error state due to misalignment.
2. underrun!!! The same error would happens as the items above.
In this patch, add variable check while adding IED header.
Adrian Alonso [Tue, 28 Aug 2012 21:35:20 +0000 (16:35 -0500)]
ENGR00215870-2: board-mx6 sabreauto fix i2c3 pad settings
* Fix i2c3 pad settings, i2c3 conflicts with weim-nor and
spi-nor only in rev b target boards.
* For rev B targets setup extra pads.
* Fix indentation.
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Robin Gong [Mon, 3 Sep 2012 07:17:01 +0000 (15:17 +0800)]
ENGR00222855 MX6 CPUFREQ: support three VDDSOC setpoints
On MX6Q/DL , there is only two set point of VDDSOC/VDDPU, one is 1.25V(1GHz),
another is 1.175V. And in arch/arm/plat-mxc/cpufreq.c will judge whether the
current cpu frequency is the highest set point(1G) or not to set the right
VDDSOC/VDDPU. The logic is also match to dynamic ldo bypass function, since the
change point is the highest set point too. But there is three set points of
VDDSOC/VDDPU in MX6SL , so the logic in cpufreq.c need to change. Now
VDDSOC/VDDPU will track with VDDARM fully.
Steve Cornelius [Thu, 30 Aug 2012 21:15:39 +0000 (14:15 -0700)]
ENGR00215875-2: caam: fix descriptor buffer overrun in hash_digest_key()
HMAC keys often need to be reduced to under the size of a digest to
be used. The driver does this psuedo-synchronously through the use of
hash_digest_key(), which builds a sequence pointered job descriptor to
perform this function.
When this function built the job descriptor, it correctly accounted for the
number of instructions and number of pointers that would go into its
construction. However, it failed to account for the fact that both the
sequence in and out pointers used extended lengths, adding 8 more bytes to
the required job descriptor. This caused the descriptor to overrun the
allocated buffer by that amount, resulting in memory corruptions.
Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com> Signed-off-by: Terry Lv <r65388@freescale.com>
Steve Cornelius [Tue, 14 Aug 2012 22:04:11 +0000 (15:04 -0700)]
ENGR00215875-1: caam: improve initalization for context state saves
Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final). Certain values in this state
block are loaded for processing using an inline-if, and when this
is done, the potential for uninitialized data can pose conflicts.
Therefore, this patch improves initialization of state data to
prevent false assignments using uninitialized data in the state block.
This patch addresses the following traceback, originating in
ahash_final_ctx(), although a problem like this could certainly
exhibit other symptoms:
ENGR00222148 [MX6SL]Shrink GPU reserved memory to 32M
MX6SL only has 512M memory.Shrinking GPU reserved memory to 32M
can help out of memory issue on MX6SL.This patch will increase
96M system memory, so it will help the case which requests lots
of system memory.Like multiple application running, etc.
And MX6SL doesn't have 3D, 32M is recommended by vivante.
ENGR00222835 MX6x-Fix incorrect enabling/disabling of PLL1
PLL1 was enabled without incrementing the usecount, and was
thus not getting disabled under certain conditions.
This causes 2 issues:
1. Increases the power.
2. Causes crashes on MX6SL in audio mode as ARM is switched
to PLL1 assuming its in bypass when entering WAIT mode. But PLL1
is enabled and not in bypass state.
ENGR00222834 MX6x-A9 prefetcher should not access DDR before IO is restored
Add enough nops to suspend code when exiting due to a pending
interrupt. This is required so that we can guarantee that the
prefetch unit will not bring DDR out of self-refresh before
all of the DDR's IO pads are restored.
Liu Ying [Fri, 31 Aug 2012 09:19:24 +0000 (17:19 +0800)]
ENGR00222197 MX6 SabreSD:Set pwm backlight max density to 248
This patch changes pwm backlight max density from 255 to 248
to workaround Hannstar LVDS panel unstable backlight issue
when density is set to 250 or 251.
ENGR00222157 MX6x-Fix bug in transitioning from low_bus to audio_bus mode.
Ensure that the transtion from low bus freq mode to
audio bus freq mode happens instantly. Don't schedule
the delayed work in this case else there will be a pause
in the audio playback.
ENGR00222257 MX6x-Prime TLB entries before DDR enters self-refresh.
Need to ensure that no page table walk occurs in DDR when it is in
self refresh and its IO pads are floated during suspend.
Hence we need to make sure that the translation of all the
addresses that the suspend code will access is in the TLB before
DDR cannot be accessed anymore.
So do a dummy read of IOMUX, MMDC, SRC and ANATOP regsiters.
Also need to add a dsb to drain all the write buffers before
DDR enters self-refresh.
Also ensure that the LDO bypass enable is reset if an interrupt
is pending before the system enters suspend.
ENGR00222134 MX6x - Fix race-conditions in low power code.
Fix couple of race-conditions associated with low power IDLE code:
1. Ensure that bus freq mutex is used in the suspend/resume function
2. Ensure that the usecount of pll2 is incremented/decremented when
ARM is switched to run from PLL2_PFD_400. And PLL2 is enabled/disabled
when necessary.
ENGR00222133 MX6SL - Fix crashes caused by Low power IDLE support
Need to ensure that the ARM_CLK rate stays exactly the same
when moving ARM_CLK from PLL2_PFD_400 to PLL1 when system
enters 24MHz state. Also need to ensure that PLL1 is enabled
before relocking the PLL to the correct rate.
Liu Ying [Thu, 30 Aug 2012 01:39:59 +0000 (09:39 +0800)]
ENGR00221370 IPUv3:Clean up IPUv3 interrupt handler
1) In the interrupt handler, we access sync interrupt
control registers 2 times, and each time with spin
lock being held and then released, which may cause
potential racing on the registers. We see that
as long as the racing happens with two displays
enabled on the same IPU, one IPU display channel
will lose EOF interrupt and it makes its fb's pan
display ioctrl fail with timeout. This patch changes
to hold the spin lock one time for the whole irq
handler, as the handler should return quickly.
Holding and releasing the spin lock unnecessarily
may bring performance penalty as well.
2) We do not need to use spin_lock_irqsave() and
spin_unlock_irqrestore() in the interrupt handler,
as we are already in the hard irq context. Using
spin_lock() and spin_unlock() is enough to protect
the registers.
3) Clear an interrupt control bit as soon as its related
handler finishes.
Liu Ying [Thu, 30 Aug 2012 01:33:01 +0000 (09:33 +0800)]
ENGR00221983 IPUv3:Correct ERR and SYNC interrupt line numbers
As we define ERR interrupt with 0 irq resource id and SYNC
interrupt with 1 irq resource id in platform-imx_ipuv3.c,
we wrongly assign them in IPUv3 driver.
projects / karo-tx-linux.git / log