Fix not re-enabling watchdog resume if it was enabled in probe
Add clearing watchdog interrupt in probe
Remove tegra_wdt_set_timeout
Change-Id: I8fdbb6da3eda64a85a73ed85ab979a5ee0261c37
Signed-off-by: Dmitriy Gruzman <dmitriy.gruzman@motorola.com>
while USB is active to eliminate all USB buffer underruns.
Change-Id: I9977224601e715e950284708958be98d37b3e6b1
Signed-off-by: Nathan Connell <w14185@motorola.com>
while USB is active to eliminate all USB buffer underruns.
Change-Id: I7ad8ebfa2d802f91b81839e14fde906da1a0569e
Signed-off-by: Nathan Connell <w14185@motorola.com>
-Add a module param to enable/disable carveout killer
-Fix race condition in code to wait for something to free memory
after firing carveout killer
-Fix the check for current so we always compare task->group_leaders
Change-Id: Ie030978827dce6b0fbbfa1db0d80e4abe59eaa51
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
This fixes a regression where hubs cannot detect new devices once they
have been auto-suspended.
Change-Id: I4b3efcaa9634b9a912060e438527000bbc83dc32
Signed-off-by: Benoit Goby <benoit@android.com>
It is seen that auto-power-gate of MPE causes some issues when long run
camera stress test is run. The issue manifest itself in the form of
MPE sync-point not getting triggered from hardware and hence the caller
who is waiting on it hangs up the system.
Disabling auto-power-gate for MPE seems to resolve this issue.
Original work of Jay Cheng <jacheng@nvidia.com>
Signed-off-by: Mayuresh Kulkarni <mkulkarni@nvidia.com>
Change-Id: Iaef9f959cbc00dd715352ca637955cd2bea6f355
-Modify the carveout killer to only kill tasks with lower priorities
than the one that's trying to allocate
-After delivering a sigkill to a task, wait for something to exit and
cleanup before retrying the allocation
Change-Id: If62b6ed008a73fc3c347ff26735a83eee284909e
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
The hardware aes engine is required for key management for
HDCP, but since it's performance is bad, we don't want it
enabled for dm-crypt. This hack changes the cra_name field
so dm-crypt won't find a match, but leaves the cra_driver_name
field unchanged to the device file interface will still find it.
Signed-off-by: Ken Sumrall <ksumrall@android.com>
- enable/disable clocks only once per request
- create a thread for handling the driver's work queue
- always set vde clocks to the max before processing a request
Change-Id: I935e5523e9e913c93705cc694f8a475d212c15ce
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
No need to maintain a reference to the task struct if the client
is a kernel thread. In this case just set the task to NULL.
Change-Id: Ica4785388932f6b298eeb0da04b78b0e1cdc3a44
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
avp does not use the crypto engine inside the vde block,
so it is ok if we do not reset the entire block before
any crypto operation. this would save more than 100us per crypto
operation.
Change-Id: I4e6f4940c5b6e95498b6f7a62498fbf956e25254
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Overlays can get their internal state corrupted during and underflow
condition. The only way to fix this state is to reset the DC. If we get
4 consecutive frames with underflows, assume we're hosed and reset.
Change-Id: Icdf61517837c8570b8de35f585075de08aa35fe7
Signed-off-by: Erik Gilling <konkers@android.com>
Cc: Michael I. Gold <gold@nvidia.com>
Add a config option to enable the watchdog driver from probe
Reduce the default timeout to 30 seconds
Read the reset reason and print a messge if the last reboot was
due to watchdog reset
Change-Id: I7500ef236089b06ffcff3d8e7d86a5b9060b59cb
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
This change attempts to reclaim carveout memory by killing
other carveout users when an allocation fails. Processes
are killed in order of priority from lowest to highest, and then
from largest to smallest users.
Change-Id: Iee8a6f36269bc8165d691000a153dbf9f4337775
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
In the TPS6586x PMU/PMIC RTC support code, when
converting from seconds to ticks using a shift
operator, the most significant bits were being lost
due to seconds being a 32-bit value and ticks being
a 64-bit value. A hard cast was added to avoid this
loss.
Reviewed-by: Lowell Dennis <ldennis@nvidia.com>
Tested-by: Lowell Dennis <ldennis@nvidia.com>
Reviewed-by: Jonathan Mayo <jmayo@nvidia.com>
Reviewed-by: Peter Zu <pzu@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Colin Cross <ccross@android.com>
To prevent USB glitch.
Also only program PTC bits when resume from LP0
Change-Id: Iced668e33f986828d3a483b411055948b5b257e1
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
Reschedule rh_timer may cause usb device resume fail, as rh_timer may be
timeout and send USB_REQ_GET_STATUS SETUP control transfer by the time when
the device is handling clear suspend feature, which in turn the device may
drop clear suspend feature request.
Actually on port resume case, the host driver don't need to reschedule
rh_timer to check port status. The host driver will check port status right
after suspend feature is cleared.
Change-Id: I6205e97af49ed4349b6215b851f6b5f1394258d8
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
Replace the PM-only driver for NCT1008 with a new version written by
Varun Wadekar and Dmitriy Gruzman. Add a callback to an alarm
function specified in the board platform data.
Change-Id: Ib429533930ee75af3402d24b0bc286da9f6ee67b
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Initial version of the NCT1008 driver to turn off the sensor when the
device is suspended. This improves standby current drain.
Change-Id: Ia64613c33c0052434d5e304c434605611e5ef789
Signed-off-by: Greg Meiste <w30289@motorola.com>
the encrypt/decrypt callbacks have to return with -EINPROGRESS
error code and the request complete callback needs to be
called from handle_req for aynchronous block ciphers. use
work queue to make the driver asynchronous.
Change-Id: I0dec1185c31e5de7ba039c39d6bd87c8b3487b2a
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
commit b2272a49e7 upstream.
The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same
value as other webcams with the same sensor. For now, only two webcams have
been so detected: the Microsoft's VX1000 and VX3000.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 229bd792be upstream.
The interrupt handler takes a lock - but since commit bcad6e80f3 this
lock goes through an indirection specified in the hermes_t structure.
We must therefore initialise the structure before setting up the
interrupt handler.
Fix orinoco_cs and spectrum_cs
<https://bugzilla.kernel.org/show_bug.cgi?id=23932>
Bisected by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit a757ee2216 upstream.
Drivers should append their name on exported symbols, to avoid
conflicts with allyesconfig:
drivers/staging/built-in.o: In function `format_by_fourcc':
/home/v4l/work_trees/linus/drivers/staging/cx25821/cx25821-video.c:96: multiple definition of `format_by_fourcc'
drivers/media/built-in.o:/home/v4l/work_trees/linus/drivers/media/common/saa7146_video.c:88: first defined here
Let's rename both occurences with a small shellscript:
for i in drivers/staging/cx25821/*.[ch]; do sed s,format_by_fourcc,cx25821_format_by_fourcc,g <$i >a && mv a $i; done
for i in drivers/media/common/saa7146*.[ch]; do sed s,format_by_fourcc,saa7146_format_by_fourcc,g <$i >a && mv a $i; done
for i in include/media/saa7146*.[ch]; do sed s,format_by_fourcc,saa7146_format_by_fourcc,g <$i >a && mv a $i; done
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit e692cb668f upstream.
When stacking devices, a request_queue is not always available. This
forced us to have a no_cluster flag in the queue_limits that could be
used as a carrier until the request_queue had been set up for a
metadevice.
There were several problems with that approach. First of all it was up
to the stacking device to remember to set queue flag after stacking had
completed. Also, the queue flag and the queue limits had to be kept in
sync at all times. We got that wrong, which could lead to us issuing
commands that went beyond the max scatterlist limit set by the driver.
The proper fix is to avoid having two flags for tracking the same thing.
We deprecate QUEUE_FLAG_CLUSTER and use the queue limit directly in the
block layer merging functions. The queue_limit 'no_cluster' is turned
into 'cluster' to avoid double negatives and to ease stacking.
Clustering defaults to being enabled as before. The queue flag logic is
removed from the stacking function, and explicitly setting the cluster
flag is no longer necessary in DM and MD.
Reported-by: Ed Lin <ed.lin@promise.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 687a993339 upstream.
While separating out BMDMA irq handler from SFF, commit c3b28894
(libata-sff: separate out BMDMA irq handler) incorrectly made
__ata_sff_port_intr() consider an IRQ to be an idle one if the host
state was transitioned to HSM_ST_ERR by ata_bmdma_port_intr().
This makes BMDMA drivers ignore IRQs reporting host bus error which
leads to timeouts instead of triggering EH immediately. Fix it by
making __ata_sff_port_intr() consider the IRQ to be an idle one iff
the state is HSM_ST_IDLE. This is equivalent to adding HSM_ST_ERR to
the "break"ing case but less error-prone.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Antonio Toma <antonio.toma@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 8333f65ef0 upstream.
use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function
aquires the spin lock that needed to protect the drivers data.
Signed-off-by: Saeed Bishara <saeed@marvell.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 63ee41d794 upstream.
The IPS driver is designed to be able to run detached from i915 and
just not enable GPU turbo in that case, in order to avoid module
dependencies between the two drivers. This means that we don't know
what the load order between the two is going to be, and we had
previously only supported IPS after (optionally) i915, but not i915
after IPS. If the wrong order was chosen, you'd get no GPU turbo, and
something like half the possible graphics performance.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 8316f33766 upstream.
The DisplayPort standard (1.1a) states that:
The I2C-over-AUX Reply field is valid only when Native AUX CH Reply
field is AUX_ACK (00). When Native AUX CH Reply field is not 00, then,
I2C-over-AUX Reply field must be 00 and be ignored.
This fixes broken EDID reading when using an active DisplayPort to
duallink DVI converter. If the AUX CH replier chooses to defer the
transaction, a short read occurs and erroneous data is returned as
the i2c reply due to a lack of length checking and failure to check
for AUX ACK.
As a result, broken EDIDs can look like:
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: bc bc bc ff bc bc bc ff bc bc bc ac bc bc bc 45 ???.???.???????E
10: bc bc bc 10 bc bc bc 34 bc bc bc ee bc bc bc 4c ???????4???????L
20: bc bc bc 50 bc bc bc 00 bc bc bc 40 bc bc bc 00 ???P???.???@???.
30: bc bc bc 01 bc bc bc 01 bc bc bc a0 bc bc bc 40 ???????????????@
40: bc bc bc 00 bc bc bc 00 bc bc bc 00 bc bc bc 55 ???.???.???.???U
50: bc bc bc 35 bc bc bc 31 bc bc bc 20 bc bc bc fc ???5???1??? ????
60: bc bc bc 4c bc bc bc 34 bc bc bc 46 bc bc bc 00 ???L???4???F???.
70: bc bc bc 38 bc bc bc 11 bc bc bc 20 bc bc bc 20 ???8??????? ???
80: bc bc bc ff bc bc bc ff bc bc bc ff bc bc bc ff ???.???.???.???.
...
which can lead to:
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>30 30 30 30 30 30 30 32 38 32 30 32 63 63 31 61 000000028202cc1a
<3>28 00 02 8c 00 00 00 00 18 00 00 00 00 00 00 00 (...............
<3>20 4c 61 73 74 20 62 65 61 63 6f 6e 3a 20 33 32 Last beacon: 32
<3>32 30 6d 73 20 61 67 6f 46 00 05 8c 00 00 00 00 20ms agoF.......
<3>36 00 00 00 00 00 00 00 00 0c 57 69 2d 46 69 20 6.........Wi-Fi
<3>52 6f 75 74 65 72 01 08 82 84 8b 96 24 30 48 6c Router......$0Hl
<3>03 01 01 06 02 00 00 2a 01 00 2f 01 00 32 04 0c .......*../..2..
<3>12 18 60 dd 09 00 10 18 02 00 00 01 00 00 18 00 ..`.............
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
[ickle: fix up some surrounding checkpatch warnings]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit a93f344d3c upstream.
On resume, we were attemping to unblank the displays before the
timing and plls had be reprogrammed which led to atom timeouts
waiting for things that are not yet programmed. Re-program
the mode first, then reset the dpms state.
This fixes the infamous atombios timeouts on resume.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9f0c4f9c2f upstream.
Only reset the grbm blocks, srbm tends to lock the GPU
if not done properly and in most cases is not necessary.
Also, no need to call asic init after reset the grbm blocks.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 86f5c9edbb upstream.
This fixes module reloading and resume as the gfx block seems to
be left in a bad state in some cases.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit bd7c72ed18 upstream.
Without this the IRQ base will not be correctly configured for the
subdevices.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit b93cef5561 upstream.
Some newer device revisions add a second parent ID. Support this in
the device validity checks done at startup.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 3b3c1f24e9 upstream.
rdc321x-wdt currently fetches its driver specific data by using the
platform_device->platform_data pointer, this is wrong because the mfd
device which registers our platform_device has been added using
mfd_add_device() which sets the platform_device->driver_data pointer
instead.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 1873bb8115 upstream.
The current code mis-calculates the ramoops header size, leading to an
overflow over the next record at best, or over a non-allocated region at
worst. Fix that calculation.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Acked-by: Marco Stornelli <marco.stornelli@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 118364948f upstream.
Match the buffer size to the amount of initialized values. Before, it was
one too big and thus destroyed the neighbouring register causing the clock
to run at false speeds.
Reported-by: Andre van Rooyen <a.v.rooyen@sercom.nl>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 274476f8fe upstream.
In the error-path where PM notifies PM_POST_RESTORE, the rescan-blockage
should be cleared as well. Otherwise it'll be never re-probed.
Also, as a bonus, this fixes a bug in S4 with user-mode suspend in the
current code, as it sends PM_POST_RESTORE instead of
PM_POST_HIBERNATION wrongly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
