Deepak Nibade [Wed, 20 Jan 2016 13:39:19 +0000 (19:09 +0530)]
video: tegra: host: use dynamically allocated wait_queue
In nvhost_syncpt_wait_timeout(), we currently allocate
wait_queue_head on stack using
DECLARE_WAIT_QUEUE_HEAD_ONSTACK()
If wait is complete, then this wait_queue_head will
removed off the stack
But in some rare case if action_wakeup_interruptible()
is called after wait is complete, we try to access
wait_queue_head which is already deleted from stack
To fix this, define wait_queue_head inside nvhost_waitlist
and allocate it dynamically along with waitlist
Ankita Garg [Wed, 23 Mar 2016 08:36:12 +0000 (01:36 -0700)]
hid: jarvis: WAR for cypress controller reset
Whenever cypress controller gets reset and
enters bootloader (version mis-match on jarvis
startup or OTA), it pulls all the buttons low,
causing spurious input events. This WAR disables
inputs when all three buttons are either pressed
or released.
Ben Hutchings [Tue, 16 Jun 2015 21:11:06 +0000 (22:11 +0100)]
pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic
pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not. The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset. This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.
This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable. This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.
with a usage count of 100 * the number of times the program has been run,
then the kernel is malfunctioning. If leaked-keyring has zero usages or
has been garbage collected, then the problem is fixed.
Increase NVAVP_MAX_RELOCATION_COUNT to max. possible value
and add check to return error if num_relocs in
nvavp_pushbuffer_submit_ioctl exceeds
NVAVP_MAX_RELOCATION_COUNT
Mathias Nyman [Mon, 3 Aug 2015 13:07:48 +0000 (16:07 +0300)]
xhci: fix off by one error in TRB DMA address boundary check
We need to check that a TRB is part of the current segment
before calculating its DMA address.
Previously a ring segment didn't use a full memory page, and every
new ring segment got a new memory page, so the off by one
error in checking the upper bound was never seen.
Now that we use a full memory page, 256 TRBs (4096 bytes), the off by one
didn't catch the case when a TRB was the first element of the next segment.
This is triggered if the virtual memory pages for a ring segment are
next to each in increasing order where the ring buffer wraps around and
causes errors like:
[ 106.398223] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
[ 106.398230] xhci_hcd 0000:00:14.0: Looking for event-dma fffd3000 trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 seg-end fffd4ff0
The trb-end address is one outside the end-seg address.
Rajath Shetty [Thu, 3 Mar 2016 01:29:31 +0000 (17:29 -0800)]
drivers: block,scsi: fixup blk_get_request dead queue scenarios
The blk_get_request function may fail in low-memory conditions or during
device removal (even if __GFP_WAIT is set). To distinguish between these
errors, modify the blk_get_request call stack to return the appropriate
ERR_PTR. Verify that all callers check the return status and consider
IS_ERR instead of a simple NULL pointer check.
For consistency, make a similar change to the blk_mq_alloc_request leg
of blk_get_request. It may fail if the queue is dead, or the caller was
unwilling to wait.
Aly Hirani [Thu, 23 Apr 2015 23:41:15 +0000 (16:41 -0700)]
drivers: video: tegra: Add full range HDMI support
HDMI sinks by default are only expected to support limited range
which restricts each channel to 16-235, rather than 0-255. The spec also
optionally allows sinks to support full range by declaring a
"quantization selectable" bit in the VCDB block in the EDID.
If the quantiazation selectable is marked as true (independent bools for
RGB/YUV), then the source is allowed to select full range by setting the
RGB/YUV limited/full range bits in the avi infoframe.
This patch adds:
1. A new VMODE flag to indicate that the specific mode is limited range
2. A new FB_CAP_* to indicate that the display supports overriding
RGB/YUV and the associated EDID parsing.
3. Applies the new VMODE LIMITED RANGE to the RGB/YUV modes based
on whether the TV supports overriding the quantization in that color
space as the default.
4. Adds the logic in the hdmi modeset to enable CMU iff we are in RGB
and limited range.
5. Adds the logic in the hdmi driver to set the avi infoframe based on
whether the current mode has the limited range flag set or not.
Change-Id: I9c42fea51211c6ed71945a17fe8f1353811951d9 Signed-off-by: Aly Hirani <ahirani@nvidia.com>
Reviewed-on: http://git-master/r/937115
GVS: Gerrit_Virtual_Submit Reviewed-by: Jon Mayo <jmayo@nvidia.com>
Arto Merilainen [Fri, 15 Jan 2016 10:41:37 +0000 (12:41 +0200)]
video: tegra: host: Update serialize flags
Currently some of the units using RESOURCE_PER_CHANNEL_INSTANCE
policy do not have .serialize flag set. As a result our recovery
cannot identify which channel is using the engine at the point
when failure occurs.
This patch enables serialization to ensure that the modules get
reset properly after failure.
Original patch source: https://android.googlesource.com/kernel/msm
Original patch commit message:
> commit 3fffc78f70dc101add8b82af878d53457713d005
> Author: Patrick Tjin <pattjin@google.com>
> Date: Wed Dec 9 15:24:05 2015 -0800
>
> net: wireless: bcmdhd: check packet length for event messages
>
> Check the datalen field is less than the size of
> packet received from the network.
>
> Bug: 25306181
>
> Signed-off-by: Patrick Tjin <pattjin@google.com>
> Change-Id: I3b021d88a95bd7d4e6e0d745d2527d73487bcadc
> (cherry picked from commit 10b850b7e82873a14068d24dac4fc2080d46ff76)
Apply slightly modified version of the following patch. (Original
patch did not handle 0 length WPS_ID_DEVICE_NAME correctly, so it was
modified to fix 0 length condition.)
Original patch source: https://android.googlesource.com/kernel/msm
Original patch commit message:
> commit 68cdc8df1cb6622980b791ce03e99c255c9888af
> Author: dataanddreams <dataanddreams@gmail.com>
> Date: Mon Nov 30 17:08:54 2015 -0500
>
> bcmdhd: Add checks for stack buffer overflows
>
> These two checks prevent exploitable buffer overflows in two scenarios.
> 1. Long WPS_ID_DEVICE_NAME in WPS info elements
> 2. Invalid SSID determined in certain scan results
>
> Bug: 25662233
> Change-Id: Ifb2887737aa6218079745f27d59b5f1364b3892e
Terje Bergstrom [Thu, 17 Dec 2015 18:12:21 +0000 (10:12 -0800)]
gpu: nvgpu: Control comptagline assignment from kernel
On Maxwell comptaglines are assigned per 128k, but preferred big page
size for graphics is 64k. Bit 16 of GPU VA is used for determining
which half of comptagline is used.
This creates problems if user space wants to map a page multiple times
and to arbitrary GPU VA. In one mapping the page might be mapped to
lower half of 128k comptagline, and in another mapping the page might
be mapped to upper half.
Turn on mode where MSB of comptagline in PTE is used instead of bit 16
for determining the comptagline lower/upper half selection.
Tobias Lindskog [Mon, 9 Feb 2015 07:10:39 +0000 (08:10 +0100)]
Shrink ashmem directly through shmem_fallocate
When ashmem_shrink is called from direct reclaim on a user thread, a
call to do_fallocate will check for permissions against the security
policy of that user thread. It can thus fail by chance if called on a
thread that isn't permitted to modify the relevant ashmem areas.
Because we know that we have a shmem file underneath, call the shmem
implementation of fallocate directly instead of going through the
user-space interface for fallocate.
Deepak Nibade [Mon, 30 Nov 2015 10:39:48 +0000 (16:09 +0530)]
gpu: nvgpu: move check_gp_put() and update_gp_get() to worker
We currently call check_gp_put() and update_gp_get()
in submit path and this takes about 5uS for both checks
check_gp_put() - 3.5 uS
update_gp_get() - 1.5 uS
But this book keeping can be moved to gk20a_channel_update()
to save some submit time
Note that check_gp_put() needs to be done inside submit
lock
Deepak Nibade [Wed, 7 Oct 2015 10:50:07 +0000 (16:20 +0530)]
gpu: nvgpu: create sync_fence only if needed
Currently, we create sync_fence (from nvhost_sync_create_fence())
for every submit
But not all submits request for a sync_fence.
Also, nvhost_sync_create_fence() API takes about 1/3rd of the total
submit path.
Hence to optimize, we can allocate sync_fence
only when user explicitly asks for it using
(NVGPU_SUBMIT_GPFIFO_FLAGS_FENCE_GET &&
NVGPU_SUBMIT_GPFIFO_FLAGS_SYNC_FENCE)
Also, in CDE path from gk20a_prepare_compressible_read(),
we reuse existing fence stored in "state" and that can
result into not returning sync_fence_fd when user asked
for it
Hence, force allocation of sync_fence when job submission
comes from CDE path
Bibhay Ranjan [Thu, 3 Dec 2015 13:04:19 +0000 (18:34 +0530)]
bcmdhd: set correct bw for p2p connection
if the bw sent from the upper layers does
not match with the bw of the AP connection,
p2p connection happens on MCC always. With
this fix, the bw of the p2p connection is
set as AP's bw.
It was typo mistake to add ! in front of of_find_property()
which caused boardinfo as null caused issue in dsi pad register
write. This change fixes it and now boardinfo read correct.
Mark Pereira [Fri, 11 Dec 2015 04:16:57 +0000 (20:16 -0800)]
Audio: update fw and driver to resolve codec issues
Change summary:
Updated xml files provided by Audience to resolve issues
with CTS capture and playback failures on Hawkeye.
Update to Hawkeye latest FW is B62297.
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.
This disallows anybody without CAP_SYS_ADMIN to read the pagemap.
Aly Hirani [Wed, 9 Dec 2015 00:21:16 +0000 (16:21 -0800)]
drivers: video: tegra: Add blacklist for a user TV
This change:
1. Adds back the blacklist mechanism from rel-22
2. Removes all existing blacklists and brings in a blacklist for a user
reported TV which does not support YUV420 4K.
- Add device tree byte streams for external state low and high.
When an external entity writes a status state to the SAR driver's external
function sar_external_status, the corresponding DT byte stream is executed
depending on the value written (0 or 1).
- Update documentation that explains this.
bytes_transferred will overflow during long audio playbacks. Since the
driver only ever consults this value modulo bytes_requested, store the value
modulo bytes_requested to prevent overflow.
BUG=chrome-os-partner:28376
TEST=Video/audio playback for >4 hours
Naveen Kumar S [Thu, 3 Dec 2015 10:25:37 +0000 (15:55 +0530)]
video: tegra: dc: remove redundant flag check
While identifying VIC, aspect ratio flag is again being
checked after comparing few basic mode parameters. Hence
removing the redundant flag comparision. This avoids failure
in VIC identification when a mode does not specify aspect ratio.
We currently allocate private command buffers (wait_cmd
and incr_cmd) before submitting the job but we never
free them explicitly.
When private command queue of the channel is full, we
then try to recycle/remove free command buffers.
But this recycling happens during submit path, and
hence that particular submit path takes much longer
Rework this as below :
- add reference of command buffers to job structure
- when job completes, free the command buffers
explicitly
- remove the code to recycle buffers since it should
not be needed now
Note that command buffers need to be freed in order of
their allocation. Ensure this with error print before
freeing the command buffer entry
Deepak Nibade [Thu, 29 Oct 2015 09:50:50 +0000 (15:20 +0530)]
gpu: nvgpu: support skipping buffer refcounting in submit
In job submission path, we always take refcount on all
the mapped buffers to safeguard against case where user
space releases the buffer early
But in case user space itself is doing proper buffer
management, kernel need not take refcounts on all the
buffers - which is also a overhead in submit path
Hence, provide a new submit flag
NVGPU_SUBMIT_GPFIFO_FLAGS_SKIP_BUFFER_REFCOUNTING to
optionally skip taking refcounts on all the buffers
Also, if we do not take refcounts, then no need to drop
any refcounts in gk20a_channel_update() as well
Deepak Nibade [Mon, 26 Oct 2015 13:17:55 +0000 (18:47 +0530)]
gpu: nvgpu: remove temporary gpfifo allocation in submit path
In GPU job submit path gk20a_ioctl_channel_submit_gpfifo(),
we currently allocate a temporary gpfifo, copy user space
gpfifo content into this temporary buffer, and then copy
temp buffer content into channel's gpfifo.
Allocation/copy/free of temporary buffer adds additional
overhead
Rewrite this sequence such that gk20a_submit_channel_gpfifo()
can receive either a pre-filled gpfifo or pointer to
user provided args.
And then we can direclty copy the user provided gpfifo
into the channel's gpfifo
Also, if command buffer tracing is enabled, we still need
to copy user provided gpfifo into temporaty buffer for reading
But that should not cause overhead in real world use case
Change-Id: I5381a60b4e86e1562804eed08bb7165b58eb6921 Signed-off-by: David Pu <dpu@nvidia.com>
Reviewed-on: http://git-master/r/836029
(cherry picked from commit 778a4f14fb4980b2a17f59375a34ca9124a0a787)
Reviewed-on: http://git-master/r/840229 Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Change-Id: I1628c717030cdc05fdc235f4aaf22591c1966108 Signed-off-by: David Pu <dpu@nvidia.com>
Reviewed-on: http://git-master/r/836392
(cherry picked from commit e7e977f3bdc9c0d06e73fda8d07447221ddffc36)
Reviewed-on: http://git-master/r/840228 Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
David Pu [Tue, 17 Nov 2015 23:12:34 +0000 (15:12 -0800)]
input: touch: sharp:fix unbalanced irq disable.
it is not multi-process safe when accessing touch driver sysfs
/sys/class/misc/touch/wakeup_enable and
/sys/class/input/input0/enabled at same time.
it leads to wakeup_enable flag inconsistent state during changing
waekup_enable and enabled node at sametime. In such case disable_irq
would be called twice and it will never comes back to balanced
state(changing between irq depth between -1 and 0 instead of 0 and 1).
This change keeps irq always enabled after touch input is enabled.
Also move enable/disable irq wake to system suspend/resume routine to
keep it always balanced.
Erik Kline [Wed, 2 Dec 2015 10:01:20 +0000 (15:31 +0530)]
neigh: Better handling of transition to NUD_PROBE state
[1] When entering NUD_PROBE state via neigh_update(), perhaps received
from userspace, correctly (re)initialize the probes count to zero.
This is useful for forcing revalidation of a neighbor (for example
if the host is attempting to do DNA [IPv4 4436, IPv6 6059]).
[2] Notify listeners when a neighbor goes into NUD_PROBE state.
By sending notifications on entry to NUD_PROBE state listeners get
more timely warnings of imminent connectivity issues.
The current notifications on entry to NUD_STALE have somewhat
limited usefulness: NUD_STALE is a perfectly normal state, as is
NUD_DELAY, whereas notifications on entry to NUD_FAILURE come after
a neighbor reachability problem has been confirmed (typically after
three probes).
Aly Hirani [Mon, 30 Nov 2015 02:37:15 +0000 (18:37 -0800)]
drivers: video: tegra: Add 1000/1001 for HDMI_EXT
Previous changed limited 1000/1001 modes to only CEA SVD. A problem
raised by this was with the modes that were read from the HDMI EXT
blocks. They supported 1000/1001 as well.
This change marks the HDMI EXT modes as such and modifies the 1000/1001
code to consider these modes too.
When turn_off_vbus_on_lp0 is set, we disconnect
VBUS before going to LP0 and re-enable it after
LP0 wakeup.
Present code assumes device speed info after LP0
is same as before LP0 which is not true if there
is a swapping of devices when system is in LP0.
Hence set speed as UNKNOWN in such condition.
Naveen Kumar S [Thu, 26 Nov 2015 09:55:39 +0000 (15:25 +0530)]
video: tegra: dc: update VIC identification
Adding few more checks to help VIC identification.
Comparing 1001/1000 value of pixclock to take care of
pclk rounding-off issue. Also, comparing mode->flag value
helps in choosing the CEA mode with matching aspect ratio.
Naveen Kumar S [Fri, 20 Nov 2015 14:15:10 +0000 (19:45 +0530)]
drivers: video: tegra: dc: Fix VIC for a few modes
This change fixes the VIC not being set correctly on a few modes. For
1000/1001 modes, the pixclock is now reverted back to the mode
corresponding to the CEA modedb before it is compared.
Since the refresh in the mode database is also not trustable, it
compares the modes from the CEA modedb with a +/- 1 offset
Aly Hirani [Mon, 23 Nov 2015 20:16:50 +0000 (12:16 -0800)]
drivers: video: tegra: Mark 1000/1001 for SVD only
As per the CEA spec, only the modes coming from the CEA SVD are capable
of the dual frame rate (that is 60 Hz also supporting 59.94, etc). This
uses the previous change to look at modes that are marked as CEA and
creates a 1000/1001 mode only for those.
Add the FB_VMODE_IS_DETAILED flag to identify detailed modes.
Add the FB_VMODE_IS_CEA flag and correctly identify
detailed timings which are also valid CEA modes.
On T124 platforms, we hit a hang on cpu_down(cpu=3) where
CPU3 gets stuck waiting on the gic irq_controller_lock in
gic_eoi_irq. The other CPUs have already entered the
DISABLE_IRQ stop machine state at this point.
This therefore causes the watchdog to timeout and the
system to reset. Given that we have the stopper thread
scheduled (preemption disabled), the 'hang scenario' most
likely manifests itself due to some sort of issue in
the irq context. Sequentially entering the DISABLE_IRQ
state from CPU3->CPU0 seem to somehow prevent this hang.
This change is only meant to be a temporary workaround
to improve system stability and is by no means a fix
of any sort. To that end, it is wrapped in a CONFIG
option that is turned off by default.
it causes bug 1706267. reverting it.
original Bug 1704518
Change-Id: I96dc461b265ea2cc56ae483fb5448e9d16e4d199 Signed-off-by: David Pu <dpu@nvidia.com>
Reviewed-on: http://git-master/r/836025 Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Damon Duan [Mon, 16 Nov 2015 08:40:00 +0000 (16:40 +0800)]
ARM64:jetson-cv: add dt support for A03 revision
Jetson-CV A03 revision needs below settings in bootloader:
- enable low-battery shut down(MBLPD)
- disable active discharge for LDO4
Add support in DT for these settings.
wireless: bcmdhd: Set/get dhd_msg_level using module param
Android utility tools to configure the msg_level in the DHD are
not available for platforms like L4T. Allow the msg_level variable
as a module param so that it can be configured at runtime via sysfs
Enabling power supply extcon interface to report
input cable type from kernel to framework layer,
adding power-supply,default-ac-cable-connected
property to set ac cable state true always.