| Age | Commit message (Collapse) | Author |
|---|
|
This commit fixes some initialization/configuration problems
that were happening with some screens due to the generation
of multiple hot plug events. This commit disables the interrupts
during a configurable period to avoid this reconfigurations that
some screens doesnt tolerate well.
Fixes #42030 for most screens. The NANNSPREE still doesnt work
very well but that monitor presents a strange behavior (also in
WinCE).
Signed-off-by: Pedro Perez de Heredia <pedro.perez@digi.com>
|
|
The masking/unmasking of events in suspend/resume is not specific to
any platform.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
Add functions to get the currently enabled events and to ascertain whether
certain event is masked on a provided event mask.
These functions will be used to mask/unmask events in suspend/resume.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
Signed-off-by: Pedro Perez de Heredia <pedro.perez@digi.com>
|
|
This commit adds the code to:
-Select a custom logo that can be used as splash screen.
-Center that logo in the screen.
Signed-off-by: Pedro Perez de Heredia <pedro.perez@digi.com>
|
|
The mc13892 driver from the BSP assumed that the battery was always
connected. Otherwise the battery driver would not be loaded.
This fix allows for the driver to work even when booting without a
battery. It modifies the battery status function to use the charger
current measured via the ADC to detect the presence of a battery and
its charging status instead of the sense bit. Also, because now the
driver can tell whether a battery is present or not, it fixes some of
the places where the driver assumed the battery would always be connected.
This fixes 42033.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
(cherry picked from commit 093ee454469036f25f104c2d544ba144d9a1ed37)
|
|
This commit enables the support for the gpios of the da9053.
This allows to manupulate that gpios (for instance in the
wireless drivers, where the wifi power enable comes from a
pmic gpio).
Not doing a power cycling on the redpine module was causing
some detection issues on some ccwmx53 modules.
Signed-off-by: Pedro Perez de Heredia <pedro.perez@digi.com>
|
|
Add a basic voltage based capacity calculation to the driver. It uses
static charge and discharge lookup tables for 25 celsius, characterized
for a hopefully generic Li-Ion battery.
This simple implementation disregards temperature and age, and it also
does not include hysteresis algorithms so the capacity may vary upon
charger connection and disconnection.
User space can still implement better algorithms using the information
provided in the sysfs.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
(cherry picked from commit 35fea3d126c91a4f25d9269ad58dc8a1c52fcd1f)
|
|
is low"
Otherwise playing fullHD videos on HDMI crashes with:
[<800303cc>] (dump_backtrace+0x0/0x10c) from [<803d4104>]
(dump_stack+0x18/0x1c)
r7:8053a048 r6:8053a048 r5:0000000c r4:00000001
[<803d40ec>] (dump_stack+0x0/0x1c) from [<800891d4>]
(__alloc_pages_nodemask+0x524/0x57c)
[<80088cb0>] (__alloc_pages_nodemask+0x0/0x57c) from [<80031a4c>]
(__dma_alloc+0xf4/0x2b8)
[<80031958>] (__dma_alloc+0x0/0x2b8) from [<80031c38>]
(dma_alloc_writecombine+0x28/0x34)
[<80031c10>] (dma_alloc_writecombine+0x0/0x34) from [<801d51e0>]
(mxcfb_set_par+0xd8/0x464)
....
This reverts commit 7c2141d484fbfa03af5f83602162d9576564121b.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
|
|
Signed-off-by: Pedro Perez de Heredia <pedro.perez@digi.com>
(cherry picked from commit e9d86e3520636c877e11cda3ef6afbf86e09b133)
Signed-off-by: Pedro Perez de Heredia <pedro.perez@digi.com>
|
|
Conflicts:
arch/arm/plat-mxc/include/mach/gpio.h
arch/x86/kernel/cpu/mtrr/main.c
drivers/mmc/core/core.c
drivers/net/smsc911x.c
fs/proc/task_mmu.c
include/linux/pm_runtime.h
mm/memory.c
mm/mlock.c
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
restructure the pm suspend/resume routines as mxc_pm_platform_data,
so split the SOC pm routines from machine pm routines.
Signed-off-by: Wayne Zou <b36644@freescale.com>
|
|
Depending on the module revision, the PMIC has one I2C address or another.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
Some regulators have the upper,lower and mask values from old datasheets
belonging to old parts.
This commit corrects them to the latest available datasheet. With this
change the values reported by the kernel now match the PMIC regulator
registers configuration and the measured values in U-Boot.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
In old PMIC versions the PERI regulator had a variable step voltage values
range.
Recent PMICs, including in all Digi modules, have a fix 25mv step size, so
remove the code that handled the variable step.
We don't have revision information from Dialog to ascertain when the
change happens, so we assume all supported PMICs are the new version.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
This commit changes the i2c address of the pmic (0x68 on the
third spin of the hardware).
It also adds a new file devices_ccxmx5x.[c,h] to place common
ccxmx51 and ccxmx53 initialization code.
Signed-off-by: Pedro Perez de Heredia <pedro.perez@digi.com>
|
|
Signed-off-by: Pedro Perez de Heredia <pedro.perez@digi.com>
|
|
The driver enables by default a window filter that stops tracking movement
if it detects a pixel difference of 50 pixels between positions. Disabling
this "feature" fixes this Vantive.
This commit allows for the driver to be configured to use the window or
not, with the default being to disable it.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
Signed-off-by: Pedro Perez de Heredia <pedro.perez@digi.com>
|
|
This battery driver is based on the da9052-battery.c driver by Dialog, and on the DVT battery scripts specific to the CCXMX53 JSK.
The following limitations apply:
- No battery temperature measurements are possible on the CCXMX53 JSK.
- No events notifications are implemented.
- No junction temperature or battery temperature monitoring.
- VBUS charging not supported by JSK.
- The only battery technology supported is Lithium-Ion.
- Only standard working temperatures are supported.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
This commit fixes the way the driver parses the command line
parameters.
It also adds the code to call the pin configuration functions
based on the bridge setup.
Signed-off-by: Pedro Perez de Heredia <pedro.perez@digi.com>
|
|
1.add VYU444 fmt to support Sii902x hdmi yuv format
2.make pixel clock from internal ipu clock more accurate
Signed-off-by: Jason Chen <b02280@freescale.com>
|
|
da9053: Fix a wrong macro definition of total register number,
which leads to overwrite read pointer in struct da9052 when
reading last register in da9053.
Signed-off-by: Wayne Zou <b36644@freescale.com>
|
|
improve mpr121 capacitive key sensitivity by change threshold of
release and touch and add a quick charge bit in init which is not
documented in MPR121's data sheet.
move macro define from header to source file.
Signed-off-by: Zhang Jiejing <jiejing.zhang@freescale.com>
|
|
As the DAI is configured as master, just swapping the LRC polarity as in
the cc9m2443 does not work. The LRC is generated by the codec.
Introduce a new DAI format configuration parameter to swap the left and
right DAC data.
This fixes #39741 for this platform.
|
|
Commit 111510be1e9bd6804c0cbec5e7a52d5563011d36 added a 'Kbuild' file
into 'ocf' directory to export sanitized 'cryptodev.h' header file to
user-space (at toolchain compilation time).
But the kernel build system gives priority to 'Kbuild' named makefiles
over 'Makefile' named ones. So the existence of a Kbuild file in that
directory makes the kernel try to use that one instead of the one
'Makefile' with the rules to build the driver.
The fix is to move the 'cryptodev.h' header to a more standard
'include/crypto' folder and export a sanitized header from there. At the
same time we update the path to that header file in the rest of the code
that includes it.
Vantive: #40057
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
(cherry picked from commit 3e9616e4dccf95e1202f658177d758c09c260d3c)
|
|
Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com>
|
|
Conflicts: gpio
Special handling of PORT A gpios is lost.
Some code has been ported but it must be fixed.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com>
|
|
Minimal change that allows to build the toolchain until FSL fixes
properly its kernel headers.
This reverts previous commit.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
|
|
Latest changes in that file make the toolchain build to fail with:
fsl_devices.h:21: included file 'linux/cdev.h' is not exported
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
|
|
[ upstream commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 ]
MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially
happen in parallel with another system wide rendezvous using
stop_machine(). This can lead to deadlock (The order in which
works are queued can be different on different cpu's. Some cpu's
will be running the first rendezvous handler and others will be running
the second rendezvous handler. Each set waiting for the other set to join
for the system wide rendezvous, leading to a deadlock).
MTRR rendezvous sequence is not implemented using stop_machine() as this
gets called both from the process context aswell as the cpu online paths
(where the cpu has not come online and the interrupts are disabled etc).
stop_machine() works with only online cpus.
For now, take the stop_machine mutex in the MTRR rendezvous sequence that
gets called from an online cpu (here we are in the process context
and can potentially sleep while taking the mutex). And the MTRR rendezvous
that gets triggered during cpu online doesn't need to take this stop_machine
lock (as the stop_machine() already ensures that there is no cpu hotplug
going on in parallel by doing get_online_cpus())
TBD: Pursue a cleaner solution of extending the stop_machine()
infrastructure to handle the case where the calling cpu is
still not online and use this for MTRR rendezvous sequence.
fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008
Reported-by: Vadim Kotelnikov <vadimuzzz@inbox.ru>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com
Cc: stable@kernel.org # 2.6.35+, backport a week or two after this gets more testing in mainline
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
[ upstream commit 93b37905f70083d6143f5f4dba0a45cc64379a62 ]
and bus reset event queuing
Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO
ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events
to be read(2) by the client. The get_info ioctl is practically always
issued right away after open, hence this condition only occurs if the
client opens during a bus reset, especially during a rapid series of bus
resets.
The problem with this condition is twofold:
- These bus reset events carry the (as yet undocumented) @closure
value of 0. But it is not the kernel's place to choose closures;
they are privat to the client. E.g., this 0 value forced from the
kernel makes it unsafe for clients to dereference it as a pointer to
a closure object without NULL pointer check.
- It is impossible for clients to determine the relative order of bus
reset events from get_info ioctl(2) versus those from read(2),
except in one way: By comparison of closure values. Again, such a
procedure imposes complexity on clients and reduces freedom in use
of the bus reset closure.
So, change the ABI to suppress queuing of bus reset events before the
first FW_CDEV_IOC_GET_INFO ioctl was issued by the client.
Note, this ABI change cannot be version-controlled. The kernel cannot
distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO
ioctl.
We will try to back-merge this change into currently maintained stable/
longterm series, and we only document the new behaviour. The old
behavior is now considered a kernel bug, which it basically is.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
[ upstream commit be98ca652faa6468916a9b7608befff215a8ca70 ]
Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Cc: <stable@kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
[ upstream commit 2efaca927f5cd7ecd0f1554b8f9b6a9a2c329c03 ]
dirty & young
I haven't reproduced it myself but the fail scenario is that on such
machines (notably ARM and some embedded powerpc), if you manage to hit
that futex path on a writable page whose dirty bit has gone from the PTE,
you'll livelock inside the kernel from what I can tell.
It will go in a loop of trying the atomic access, failing, trying gup to
"fix it up", getting succcess from gup, go back to the atomic access,
failing again because dirty wasn't fixed etc...
So I think you essentially hang in the kernel.
The scenario is probably rare'ish because affected architecture are
embedded and tend to not swap much (if at all) so we probably rarely hit
the case where dirty is missing or young is missing, but I think Shan has
a piece of SW that can reliably reproduce it using a shared writable
mapping & fork or something like that.
On archs who use SW tracking of dirty & young, a page without dirty is
effectively mapped read-only and a page without young unaccessible in the
PTE.
Additionally, some architectures might lazily flush the TLB when relaxing
write protection (by doing only a local flush), and expect a fault to
invalidate the stale entry if it's still present on another processor.
The futex code assumes that if the "in_atomic()" access -EFAULT's, it can
"fix it up" by causing get_user_pages() which would then be equivalent to
taking the fault.
However that isn't the case. get_user_pages() will not call
handle_mm_fault() in the case where the PTE seems to have the right
permissions, regardless of the dirty and young state. It will eventually
update those bits ... in the struct page, but not in the PTE.
Additionally, it will not handle the lazy TLB flushing that can be
required by some architectures in the fault case.
Basically, gup is the wrong interface for the job. The patch provides a
more appropriate one which boils down to just calling handle_mm_fault()
since what we are trying to do is simulate a real page fault.
The futex code currently attempts to write to user memory within a
pagefault disabled section, and if that fails, tries to fix it up using
get_user_pages().
This doesn't work on archs where the dirty and young bits are maintained
by software, since they will gate access permission in the TLB, and will
not be updated by gup().
In addition, there's an expectation on some archs that a spurious write
fault triggers a local TLB flush, and that is missing from the picture as
well.
I decided that adding those "features" to gup() would be too much for this
already too complex function, and instead added a new simpler
fixup_user_fault() which is essentially a wrapper around handle_mm_fault()
which the futex code can call.
[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix some nits Darren saw, fiddle comment layout]
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reported-by: Shan Hai <haishan.bai@gmail.com>
Tested-by: Shan Hai <haishan.bai@gmail.com>
Cc: David Laight <David.Laight@ACULAB.COM>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Darren Hart <darren.hart@intel.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit 2aa15890f3c191326678f1bd68af61ec6b8753ec upstream.
Michael Leun reported that running parallel opens on a fuse filesystem
can trigger a "kernel BUG at mm/truncate.c:475"
Gurudas Pai reported the same bug on NFS.
The reason is, unmap_mapping_range() is not prepared for more than
one concurrent invocation per inode. For example:
thread1: going through a big range, stops in the middle of a vma and
stores the restart address in vm_truncate_count.
thread2: comes in with a small (e.g. single page) unmap request on
the same vma, somewhere before restart_address, finds that the
vma was already unmapped up to the restart address and happily
returns without doing anything.
Another scenario would be two big unmap requests, both having to
restart the unmapping and each one setting vm_truncate_count to its
own value. This could go on forever without any of them being able to
finish.
Truncate and hole punching already serialize with i_mutex. Other
callers of unmap_mapping_range() do not, and it's difficult to get
i_mutex protection for all callers. In particular ->d_revalidate(),
which calls invalidate_inode_pages2_range() in fuse, may be called
with or without i_mutex.
This patch adds a new mutex to 'struct address_space' to prevent
running multiple concurrent unmap_mapping_range() on the same mapping.
[ We'll hopefully get rid of all this with the upcoming mm
preemptibility series by Peter Zijlstra, the "mm: Remove i_mmap_mutex
lockbreak" patch in particular. But that is for 2.6.39 ]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Reported-by: Michael Leun <lkml20101129@newton.leun.net>
Reported-by: Gurudas Pai <gurudas.pai@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Acked-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
[ Upstream commit 13fcb7bd322164c67926ffe272846d4860196dc6 ]
In 2.6.27, commit 393e52e33c6c2 (packet: deliver VLAN TCI to userspace)
added a small information leak.
Add padding field and make sure its zeroed before copy to user.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
CC: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit b3eec79b0776e5340a3db75b34953977c7e5086e ]
Add a generic mechanism to ratelimit WARN(foo, fmt, ...) messages
using a hidden per call site static struct ratelimit_state.
Also add an __WARN_RATELIMIT variant to be able to use a specific
struct ratelimit_state.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit b5199515c25cca622495eb9c6a8a1d275e775088 upstream.
The clocksource watchdog code is interruptible and it has been
observed that this can trigger false positives which disable the TSC.
The reason is that an interrupt storm or a long running interrupt
handler between the read of the watchdog source and the read of the
TSC brings the two far enough apart that the delta is larger than the
unstable treshold. Move both reads into a short interrupt disabled
region to avoid that.
Reported-and-tested-by: Vernon Mauery <vernux@us.ibm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit dc5f219e88294b93009eef946251251ffffb6d60 upstream.
Xen needs to reenable interrupts which are marked IRQF_NO_SUSPEND in the
resume path. Add a flag to force the reenabling in the resume code.
Tested-and-acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller <miltonm@bga.com>
Cc: <linuxppc-dev@lists.ozlabs.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This reverts commit 142d439b5804fc734ad892486a163be369ed6992.
This belongs in the Android branch.
|
|
This patch supports HW triple buffer for IPUv3
framebuffer.
1) Remove buf ready check in EOF irq handler, as we
think the swap logic will not fail for HW triple
buffer case.
2) When V4L2 output/overlay are used, switch to double
buffer mode.
3) Changes IPU interface for IPUv1 framebuffer to pass
building.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
Signed-off-by: Jason Chen <b02280@freescale.com>
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
This patch supports IPUv3 triple buffer.
Only channel 23, 27 and 28 are tested.
Test was done on MX51 BBG and MX53 SMD.
IPUv1 interface is changed accordingly
to pass building.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
After mx50 hdmi patches in, it make issues of mx53 platform.
This patch fix such issues on mx53 like:
1. dual display will make edid video mode into both fb0 and fb1
2. after v4l2 output playback, fb0 will be blank.
Signed-off-by: Jason Chen <b02280@freescale.com>
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
Add mc34708 i2c driver support for mx53 Ripley Quick Start board,
and fix some compile warning.
Signed-off-by: Zou Weihua -wayne zou <b36644@freescale.com>
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
MLB can't support 1024fs data transfer.
Need to enable MLBCLK_IN_INV in IOMUXC.IOMUXC_GPR0.
Signed-off-by: Terry Lv <r65388@freescale.com>
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
Add DA9053 version detection
Signed-off-by: Zhou Jingyu <Jingyu.Zhou@freescale.com>
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
If you disable display, the display port's pin may keep high voltage which
may cause power leakage. Fix this issue by make all pin go into low level
after display disable.
Signed-off-by: Jason Chen <b02280@freescale.com>
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
add four kinds of camera rotate function: rotate_none, rotate_vert
rotate_horiz, rotate_180
Signed-off-by: Yuxi Sun <b36102@freescale.com>
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
|
add power off interface for da9053
Signed-off-by: Zhou Jingyu <Jingyu.Zhou@freescale.com>
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
|
