Age | Commit message (Collapse) | Author |
|
[Rabin VINCENT]
This is for I$-D$ coherence issues when bounce buffers are used
for the MMC driver and code is executed from a file system on
eMMC.
IMO a better fix is to either change flush_kernel_dcache_page()
to flush the D$ even on VIPT non-aliasing caches or to replace
the flush_kernel_dcache_page() in lib/scatterlist.c with
flush_dcache_page().
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Add changes to V4L needed by LTP test.
Signed-off-by: Robert Marklund <robert.marklund@stericsson.com>
|
|
This patch adds support for the ST-Ericsson CG2900
Connectivity Combo controller (Bluetooth, FM, GPS).
Signed-off-by: Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
Signed-off-by: Robert Marklund <robert.marklund@stericsson.com>
|
|
commit e20a2d205c05cef6b5783df339a7d54adeb50962 upstream.
Older AMD K8 processors (Revisions A-E) are affected by erratum
400 (APIC timer interrupts don't occur in C states greater than
C1). This, for example, means that X86_FEATURE_ARAT flag should
not be set for these parts.
This addresses regression introduced by commit
b87cf80af3ba4b4c008b4face3c68d604e1715c6 ("x86, AMD: Set ARAT
feature on AMD processors") where the system may become
unresponsive until external interrupt (such as keyboard input)
occurs. This results, for example, in time not being reported
correctly, lack of progress on the system and other lockups.
Reported-by: Joerg-Volker Peetz <jvpeetz@web.de>
Tested-by: Joerg-Volker Peetz <jvpeetz@web.de>
Acked-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Boris Ostrovsky <Boris.Ostrovsky@amd.com>
Link: http://lkml.kernel.org/r/1304113663-6586-1-git-send-email-ostr@amd64.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 94024cd1aefa0f8bcc9dfe46c05bd7ce3f471a1c upstream.
The PCI SSID is 1025:031c and the codec SSID is 1025:031d,
so the driver mistakes this for a SKU value, but looking at
the numbers, this is obviously wrong.
BugLink: http://bugs.launchpad.net/bugs/761861
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This patch removes a warning in order to reach a point where
we have zero warnings and Hudson can start to give -1 results
on any added ones.
This patch shall never reach mainline.
ST-Ericsson Linux next: Never
ST-Ericsson ID: -
ST-Ericsson FOSS-OUT ID: Trivial
Signed-off-by: Jonas Aaberg <jonas.aberg@stericsson.com>
Change-Id: Ic80fb9b7280a52c1e03948de91b602d148b1a760
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/17154
Reviewed-by: Mattias WALLIN <mattias.wallin@stericsson.com>
|
|
udelay() can be incorrect on SMP machines that scale their CPU
frequencies independently of one another (as pointed out here
http://article.gmane.org/gmane.linux.kernel/977567). The delay
loop can either be too fast or too slow depending on which CPU the
loops_per_jiffy counter is calibrated on and which CPU the delay
loop is running on. udelay() can also be incorrect if the
CPU frequency switches during the __delay() loop, causing the loop
to either terminate too early, or too late.
Forcing udelay() to run on one CPU is unreasonable and taking the
penalty of a rather large loops_per_jiffy in udelay() when the
CPU is actually running slower is bad for performance. Solve the
problem by adding a timer based__delay() loop unaffected by CPU
frequency scaling. Machines should set this loop as their
__delay() implementation by calling set_timer_fn() during their
timer initialization.
The kernel is already prepared for a timer based approach
(evident by the read_current_timer() function). If an arch
implements read_current_timer(), calibrate_delay() will use
calibrate_delay_direct() to calculate loops_per_jiffy (in which
case loops_per_jiffy should really be renamed to
timer_ticks_per_jiffy). Since the loops_per_jiffy will be based
on timer ticks, __delay() should be implemented as a loop around
read_current_timer().
Doing this makes the expensive loops_per_jiffy calculation go
away (saving ~150ms on boot time on my machine) and fixes
udelay() by making it safe in the face of independently scaling
CPUs. The only prerequisite is that read_current_timer() is
monotonically increasing across calls (and doesn't overflow
within ~2000us).
There is a downside to this approach though. BogoMIPS is no
longer "accurate" in that it reflects the BogoMIPS of the timer
and not the CPU. On most SoC's the timer isn't running anywhere
near as fast as the CPU so BogoMIPS will be ridiculously low (my
timer runs at 4.8 MHz and thus my BogoMIPS is 9.6 compared to my
CPU's 800). This shouldn't be too much of a concern though since
BogoMIPS are bogus anyway (hence the name).
This loop is pretty much a copy of AVR's version.
Reported-and-reviewed-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Change-Id: I9a4bee236ff1f26e1f2ae7e15e92b9ba14b46952
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/13564
Tested-by: Mattias WALLIN <mattias.wallin@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
Some machines want to implement their own __delay() routine based
on fixed rate timers. Expose functionality to set the __delay()
routine at runtime. This should allow two machines with different
__delay() routines to happily co-exist within the same kernel
with minimal overhead.
Russell expressed concern that using a timer based __delay()
would cause problems when an iomapped device isn't mapped in
prior to a delay call being made (see
http://article.gmane.org/gmane.linux.ports.arm.kernel/78543 for
more info). We can sidestep that issue with this approach since
the __delay() routine _should_ only be pointed to a timer based
delay once the timer has been properly mapped. Up until that
point __delay() and udelay() will use delay_loop() which is
always safe to call.
This patch is inspired by x86's delay.c
Reviewed-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Change-Id: I269f101b40ba50c2b635dc92d50f6e82bb934b32
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/13563
Tested-by: Mattias WALLIN <mattias.wallin@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
We want to allow machines to override the __delay() implementation
at runtime so they can use a timer based __delay() routine. It's
easier to do this using C, so let's write udelay and friends in C.
We lose the #if 0 code, which according to Russell is used "to
make the delay loop more stable and predictable on older CPUs"
(see http://article.gmane.org/gmane.linux.kernel/888867 for more
info). We shouldn't be too worried though, since we'll soon add
functionality allowing a machine to set the __delay() loop
themselves, thus allowing machines to resurrect the commented out
code should they need it.
Nico expressed concern that fixed lpj cmdlines will break due to
compiler optimizations. That doesn't seem to be the case since
before and after this patch I get the same lpj value when running
my CPU at 19.2 MHz. That should be sufficiently slow enough to
cover any machine running Linux.
Reviewed-by: Saravana Kannan <skannan@codeaurora.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Change-Id: I84311dc3955250960ffa8dc56d45a4833b3ad0f2
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/13562
Tested-by: Mattias WALLIN <mattias.wallin@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
Conflicts:
arch/arm/lib/delay.S
|
|
This patch adds functions to flush and clean the entire data cache.
Since the existing flush/clean range functions take more time to
flush/clean the entire data cache, they cannot be used.
Whenever the range of data to be flushed/cleaned from the data cache
is more than some threshold value, it is better to do the entire data
flush/clean, this will reduce the time taken and effectively
increases the performance of the system.
ST-Ericsson ID: IR275682 ER275397
Change-Id: I8d7e6004232301cc2c9922738fa728cdc833cfde
Signed-off-by: Johan Mossberg <johan.xx.mossberg@stericsson.com>
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/7161
Reviewed-by: Robert FEKETE <robert.fekete@stericsson.com>
Reviewed-by: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
Conflicts:
arch/arm/mm/cache-v7.S
|
|
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
|
|
Signed-off-by: Sundar R Iyer <sundar.iyer@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
|
|
On the v1.0/ED boards, during the deep sleep resume, it is
required to make the backup RAM area as "executable" in order
manage MMU settings for a single core mode. As a result, the
rom code requires such a condition for aligning SMP strategy
for different per-core MMU configuration. This patch makes
the backup RAM configuration area as executable by adding
a new memory type.
*This change will not be needed for U8500 v2.0 as the
rom code would (hopefully as discussions are showing) be updated
with a minor API change*
This patch is a part of patches for the deep sleep feature
for the U8500 and FIDO_IR_ER: 258539
This patch *must* be re-visisted during u8500 v2.0 cut
or mainlining the deep sleep to community
Signed-off-by: Sundar R Iyer <sundar.iyer@stericsson.com>
Acked-By: Biju C Das <biju.das@stericsson.com>
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Change-Id: Id4d8215ca1e9aaf8f327ff3f55f3f9ca1e68aef5
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/2190
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
The default setting of 128 is not close to enough to save
all the names of processes/threads executed during 1s
of idle in Android.
ST-Ericsson Linux next: -
ST-Ericsson ID: -
ST-Ericsson FOSS-OUT ID: Trivial
Signed-off-by: Jonas Aaberg <jonas.aberg@stericsson.com>
Change-Id: I6f9ef8d5f167f4b1f8de7b996130e65ee5fc7598
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/15157
Reviewed-by: Martin PERSSON <martin.persson@stericsson.com>
Reviewed-by: Mattias WALLIN <mattias.wallin@stericsson.com>
|
|
This patch will make the threaded nested handler run all the registered
shared action handlers and not just the first registered.
Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com>
Change-Id: Ib484a2fa50186dbc05aedbcb9936518302ab801b
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/10494
Reviewed-by: Rabin VINCENT <rabin.vincent@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Change-Id: Ie73cf9782ccbf3a974383fa5d1474613c660c6b9
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/3172
Tested-by: Mian Yousaf KAUKAB <mian.yousaf.kaukab@stericsson.com>
Reviewed-by: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
|
|
Makes low-level printk work.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
|
|
|
|
|
|
|
|
Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
|
|
Signed-off-by: Philippe Langlais <philippe.langlais@stericsson.com>
|
|
To locate the consumer(s) that currently holds
(ie have enabled) a regulator, a new sysfs entry
is created. The consumer(s) are published in
/sys/class/regulator/regulator.<#>/use
Signed-off-by: Martin Persson <martin.persson@stericsson.com>
Change-Id: Ief78276c9685d0bf5688294b9aed9e0698c3475f
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/6549
Reviewed-by: Bengt JONSSON <bengt.g.jonsson@stericsson.com>
Conflicts:
drivers/regulator/core.c
|
|
This patch is based on the following work:
Add a power management scheme for AB3550 and fix bugs that hinder simultaneous playback/capture.
ST-Ericsson ID: WP 259100
Author: Xie Xiaolei <xie.xiaolei@stericsson.com>
msp: add configuration param for MSP_IODLY
ST-Ericsson ID: CR261462
Author: Rabin Vincent <rabin.vincent@stericsson.com>
ab8500-acodec: remove unused dma variables
ST-Ericsson ID: AP259210
Author: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
|
|
|
|
|
|
The intensity of the backlight/led can be varied from a range of
max_brightness to zero. Though most, if not all the pwm based
backlight/led devices start flickering at lower brightness value.
And also for each device there exists a brightness value below
which the backlight appears to be turned off though the value is
not equal to zero.
If the range of brightness for a device is from zero to
max_brightness. A graph is plotted for brightness Vs intensity fo the
pwm based backlight/led device has to be a linear graph.
intensity
| /
| /
| /
|/
---------
0 max_brightness
But pratically on measuring the above we note that the intensity of
backlight/led goes to zero(OFF) when the value in not zero almost nearing to
zero(some x%). so the graph looks like
intensity
| /
| /
| /
| |
------------
0 x max_brightness
In order to overcome this drawback knowing this x% i.e nothing but the
low threshold beyond which the backlight/led is off and will have no effect,
the brightness value is being offset by the low threshold
value(retaining the linearity of the graph). Now the graph becomes
intensity
| /
| /
| /
| /
-------------
0 max_brightness
With this for each and every digit increment in the brightness from zero
there is a change in the intensity of backlight/led.
Devices having this behaviour can set the low threshold
brightness(lth_brightness) and pass the same as platform data else can
have it as zero.
ST-Ericsson ID: Task168737
Change-Id: I7198ec89aa69e0c687d329b21f723fd8d5368928
Signed-off-by: Prajadevi H <prajadevi.h@stericsson.com>
Signed-off-by: Arun Murthy <arun.murthy@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/5231
Reviewed-by: Linus WALLEIJ <linus.walleij@stericsson.com>
|
|
This patch is based on the following work:
Keypad tc35893: Fix the Keypad Driver interrupt enable/disable
ST-Ericsson ID: ER274519
Author: Ankur Vaish <ankur.vaish@stericsson.com>
Keypad: Disable EV_REP to disable reporting repeated key events
ST-Ericsson Id:ER 264416
Author: Jayeeta Banerjee <jayeeta.banerjee@stericsson.com>
Add support for TC35893 Keypad Controller
ST-Ericsson ID: AP261147
Author: Jayeeta Banerjee <jayeeta.banerjee@stericsson.com>
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
|
|
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
|
|
|
|
Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
|
|
Add the regulator calls for the ske keypad
controller driver.
ST-Ericsson Id: AP 323445
Change-Id: I950ce9c9415bc283e2d9c3174f7178b2f5555248
Signed-off-by: Naveen Kumar Gaddipati <naveen.gaddipati@stericsson.com>
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/14806
Reviewed-by: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
|
|
Decrease the CPU load during continuous key press in
SKE keypad driver.
ST-Ericsson Id: ER 323157
Signed-off-by: Naveen Kumar Gaddipati <naveen.gaddipati@stericsson.com>
Change-Id: Ic450157de6cb21d3d36a51ffb54e5d3467163335
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/14705
Reviewed-by: QATOOLS
Reviewed-by: Rikard OLSSON <rikard.p.olsson@stericsson.com>
Reviewed-by: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
|
|
Remove the multiple interrupts for each key press
of the ske keypad.
ST-Ericsson Id: ER 323157
Change-Id: Ib0d9827895c72c47e83006a1498401849c1c16db
Signed-off-by: Naveen Kumar Gaddipati <naveen.gaddipati@stericsson.com>
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/14599
Reviewed-by: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
|
|
Suspend and resume support for ske keypad by
using disable or enable of keypad.
ST-Ericsson Id: ER 320090
Change-Id: I5ae732be0e2f6074048fa6351a9f7b9ee33f380f
Signed-off-by: Naveen Kumar Gaddipati <naveen.gaddipati@stericsson.com>
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/13977
Reviewed-by: QATOOLS
Reviewed-by: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
|
|
Added the multi key press support for SKE keypad by modifying the irq
function for handling the two different keys on the same column and also
pressing the two different keys of different columns on
the same ASR register.
ST-Ericsson Id: ER 279197
Signed-off-by: Naveen Kumar Gaddipati <naveen.gaddipati@stericsson.com>
Change-Id: Ia83a8f6ba1f5fee47f97b9476bb59cf2460b8e14
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/13192
Reviewed-by: QATOOLS
Reviewed-by: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
|
|
ST-Ericcson ID: TASK_ER170552
Change-Id: Id814bec06a86e8a3215ef662d5f01a7ee929d26a
Signed-off-by: Sundar Iyer <sundar.iyer@stericsson.com>
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/7526
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
Added support for dynamic enable or disable of
STMPE1601 keypad events by using sysfs commands.
Enable STMPE1601 keypad event:
echo 1 > /sys/devices/platform/nmk-i2c.0/i2c-0/0-0040/stmpe-keypad.1/enable
Disable STMPE1601 keypad event:
echo 0 > /sys/devices/platform/nmk-i2c.0/i2c-0/0-0040/stmpe-keypad.1/enable
ST-Ericsson Id: WP 273474
Change-Id:I12281c9a3ae3b275b3e1efaeecfb7817c93290b9
Signed-off-by: Bade Appala Naidu <appala.bade@stericsson.com>
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/6266
Reviewed-by: Linus WALLEIJ <linus.walleij@stericsson.com>
|
|
ST-Ericsson ID: AP273221
Change-Id: I0f096b8364797595084a84cb61bf13de61a3c0a2
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/5408
Tested-by: Rabin VINCENT <rabin.vincent@stericsson.com>
Tested-by: build servers
Reviewed-by: Linus WALLEIJ <linus.walleij@stericsson.com>
|
|
Added support for dynamic enable or disable of
SKE keypad events by using sysfs commands.
Enable SKE keypad event:
echo 1 >/sys/devices/platform/nmk-ske-keypad/enable
Disable SKE keypad event:
echo 0 >/sys/devices/platform/nmk-ske-keypad/enable
ST-Ericsson Id: WP 273474
Change-Id:Ia7c98d67609129ee661eec2b3f036bc24402b166
Signed-off-by: Naveen Kumar Gaddipati <naveen.gaddipati@stericsson.com>
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/6202
Reviewed-by: Linus WALLEIJ <linus.walleij@stericsson.com>
|
|
The platform bus type is often used to handle Systems-on-a-Chip (SoC)
where all devices are represented by objects of type struct
platform_device. In those cases the same "platform" device driver
may be used with multiple different system configurations, but the
actions needed to put the devices it handles into a low-power state
and back into the full-power state may depend on the design of the
given SoC. The driver, however, cannot possibly include all the
information necessary for the power management of its device on all
the systems it is used with. Moreover, the device hierarchy in its
current form also is not suitable for representing this kind of
information.
The patch below attempts to address this problem by introducing
objects of type struct dev_power_domain that can be used for
representing power domains within a SoC. Every struct
dev_power_domain object provides a sets of device power
management callbacks that can be used to perform what's needed for
device power management in addition to the operations carried out by
the device's driver and subsystem.
Namely, if a struct dev_power_domain object is pointed to by the
pwr_domain field in a struct device, the callbacks provided by its
ops member will be executed in addition to the corresponding
callbacks provided by the device's subsystem and driver during all
power transitions.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Tested-and-acked-by: Kevin Hilman <khilman@ti.com>
ST-Ericsson Linux next: -
ST-Ericsson ID: ER323382
ST-Ericsson FOSS-OUT ID: Trivial
Change-Id: I1f21456339aaa75905694bf4d87912b762c9d85e
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/16674
Tested-by: Rabin VINCENT <rabin.vincent@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
trace and scheduler wakeup/context switch tracing
Change-Id: I6621cfceccc4f000e9196d2d8909f0493d5d4774
Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
Signed-off-by: Robert Marklund <robert.marklund@stericsson.com>
|
|
U5500 is not yet supported.
Signed-off-by: Pierre Peiffer <pierre.peiffer@stericsson.com>
Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
|
|
Change-Id: I5a53335d41ac1ecda02dc61d68a418a0039ebdff
Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
Signed-off-by: Robert Marklund <robert.marklund@stericsson.com>
|
|
|
|
Hall effect sensor is managed as an input event (SW_LID),
same management as proximity sensor
Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
|
|
1) Increase RX FIFO threshold so that there
is a reduction in the number of interrupts
handled to complete a transaction.
2) Fill TX FIFO in the write function.
ST-Ericsson ID: ER 326383
Change-Id: Ib75946bed8fdb3f81dfa0e2ffeb29d6ba0be36bb
Signed-off-by: Virupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com>
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/17473
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
It is seen that i2c-nomadik controller randomly stops
generating the interrupts leading to a i2c timeout.
As a workaround to this problem add retries, to the on going
transfer on failure.
Since this behaviour does not get changed with a wait for
longer duration, the timeout can be reduced to a lower
value, leading to a quicker retry attempt.
ST-Ericsson ID: ER 325661
Signed-off-by: Virupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com>
Change-Id: Ic9db2b15ff5ce7e656cbbdfeb19270da9e32f9d1
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/16972
Tested-by: Virupax SADASHIVPETIMATH <virupax.sadashivpetimath@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|
|
Use the pm_runtime API for pins control.
ST-Ericsson Linux next: -
ST-Ericsson ID: ER323382
ST-Ericsson FOSS-OUT ID: Trivial
Change-Id: Ib847143b96950c25221c6aa25dae541017840677
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/16045
Tested-by: Rabin VINCENT <rabin.vincent@stericsson.com>
Reviewed-by: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
|