Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge: cm12.1 to cancro-kk-oss #1

Closed
wants to merge 129 commits into from

Conversation

ajitkatte
Copy link

No description provided.

dhacker29 and others added 30 commits April 4, 2015 23:55
Export audio_effects.h for userland to use

Change-Id: Ib4b040a87bcf89542d8c9dfb363fcd5f9a1bfc76
This patch fixes wrong memcpy size when copying ltk value to
HCI_OP_LE_LTK_REPLY command.

Change-Id: I44e5e3da15369d4b424581720ccd3bac820ef2e0
The gcc warns like:

  cpufreq_interactive.c:745:6: warning: operation on 'ret' may be
undefined [-Wsequence-point]

It was introduced by commit cf0fad49d17cb8273ce555dd5b7afab67d7923bf.

Since sprintf(...) just return 1 (one character) in this case, ret
should not changed.
Just discarding the result of sprintf(...) leads to the result that
the committer of cf0fad49d17cb8273ce555dd5b7afab67d7923bf wants.

Change-Id: Ifed1cef6d6a31c3ed23dad03a567b3b9eddf3a57
Signed-off-by: Chih-Wei Huang <cwhuang@android-x86.org>
Signed-off-by: Dave Daynard <nardholio@gmail.com>
Send LDO notification through SMD channel to FW which use
to update the pmic pam map.

Change-Id: I7a893570489e65d92df65728d09fd20e61d6b0fc
CRs-Fixed: 660361
Signed-off-by: Hardik Kantilal Patel <hkpatel@codeaurora.org>
wcnss driver doing multiple pil retry which causing boot process
block upto all pil retry finish. reduce the pil retry count so
it will not delay other boot process.

Change-Id: I646f444042ee7b64995a1117ae4cc7191ab85708
CRs-Fixed: 688990
Signed-off-by: Hardik Kantilal Patel <hkpatel@codeaurora.org>
Add null check for pm_ops in pm_ops unregister to avoid
null pointer dereference.

Change-Id: I885618a3244b91ba5eddcadb81ae08e965db63b3
CRs-Fixed: 690191
Signed-off-by: Mahesh A Saptasagar <msapta@codeaurora.org>
Add CNSS platform driver API to expose monotonic boot time so that
WLAN host driver can get the timestamp.

Change-Id: I722fa42600bf910254ac01a7305bbbaa35dfa83e
CRs-Fixed: 706813
Signed-off-by: Hardik Kantilal Patel <hkpatel@codeaurora.org>
To avoid ADC_TM interrupts at 3.5V battery threshold
Change WCNSS_VBATT_GUARD value from 200uV to 20mV.

Change-Id: I2d7a637ff4c3eb820c43fcb73d1720e94edf3c4c
CRs-Fixed: 705609
Signed-off-by: Anand N Sunkad <asunka@codeaurora.org>
Add pm_qos support to prevent power collapse of BIMC during
SSR and coldboot. Wakelock is also taken to prevent power
collapse of BIMC

CRs-Fixed: 727070
Change-Id: Ida638e85995735b629ad455dd48df996b37c2305
Signed-off-by: Siddharth Bhal <sbhal@codeaurora.org>
Add support to check for pronto ver3 hardware is present
by reading a device tree entry

Change-Id: I01cd71ac6c00b6c1e4c5ea46b3f3c0b57a0dbd95
CRs-Fixed: 737209
Signed-off-by: Siddharth Bhal <sbhal@codeaurora.org>
To dynamically configure GPIO strength in firmware
send GPIO strength parameter as a part of power manager
indication to firmware.

Change-Id: Iad9351d079a61321d407ca1032add841f16c8fdd
CRs-Fixed: 765151
Signed-off-by: Anand N Sunkad <asunka@codeaurora.org>
Sometimes dumping IRIS register along with PRONTO register
results in crash.
To mitigate issue get MUX control before dumping IRIS register.

Change-Id: Ie1e19a254ec1ae43c2713c86c4d35a2d9968bcd6
CRs-Fixed: 777663
Signed-off-by: Anand N Sunkad <asunka@codeaurora.org>

Conflicts:
	drivers/net/wireless/wcnss/wcnss_wlan.c
	include/linux/wcnss_wlan.h
In wcnssctrl_rx_handler value of len could become negative
after substracting sizeof(struct smd_msg_hdr) from len.
There is no check to verify if value of len is less than
sizeof(struct smd_msg_hdr).

Adds proper check to verify if value of len is less than
sizeof(struct smd_msg_hdr).

Change-Id: I8a3bc9eb63e1b232023444bb8258bcdaccfa1c34
CRs-Fixed: 633938
Signed-off-by: Abhishek Singh <absingh@codeaurora.org>
Dump IRIS register during Wdog bite and sending FIQ to confirm
if XO enable command was ever received or not.
Add debug log when SMD msg header is unavialable completely.

Change-Id: I514420c6d556a6aab838971fd050966698d7d3fd
CRs-Fixed: 769672
Signed-off-by: Anand N Sunkad <asunka@codeaurora.org>

Conflicts:
	drivers/net/wireless/wcnss/wcnss_wlan.c
 * MDP 4.2 supports Polynomial Color Correction. Use this to implement
   a simple sysfs API for adjusting RGB scaling values. This can be
   used to implement color temperature and other controls.
 * Why use this when we have KCAL? This code is dead simple, the
   interface is in the right place, and it allows for 128X accuracy.

Change-Id: Ie17c84ee3c1092ea65804566bdf05326a34a6d4d
  Set mtune=cortex-a7 for msm8916

Change-Id: Id7af198b0650ab224b7216a9285ed94d7c0928bc
Signed-off-by: Jiangli Yuan <jlyuan@motorola.com>
Change the flag to vendor command from NL80211_FLAG_NEED_WIPHY to
NL80211_FLAG_NEED_NETDEV

Change-Id: Ia7a99a326b87f4d6caa4b1b8a60943c03a757cb0
Signed-off-by: Jing Ji <a5705c@motorola.com>
Reviewed-on: http://gerrit.mot.com/647903
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Igor Kovalenko <igork@motorola.com>
SLTApproved: Christopher Fries <cfries@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
The default initial rwnd is hardcoded to 10.

Now we allow it to be controlled via
  /proc/sys/net/ipv4/tcp_default_init_rwnd
which limits the values from 3 to 100

This is somewhat needed because ipv6 routes are
autoconfigured by the kernel.

See "An Argument for Increasing TCP's Initial Congestion Window"
in https://developers.google.com/speed/articles/tcp_initcwnd_paper.pdf

Change-Id: I386b2a9d62de0ebe05c1ebe1b4bd91b314af5c54
Signed-off-by: JP Abgrall <jpa@google.com>

Conflicts:
	include/net/tcp.h
[ Upstream commit 13eb2ab ]

When trying to delete a table >= 256 using iproute2 the local table
will be deleted.
The table id is specified as a netlink attribute when it needs more then
8 bits and iproute2 then sets the table field to RT_TABLE_UNSPEC (0).
Preconditions to matching the table id in the rule delete code
doesn't seem to take the "table id in netlink attribute" into condition
so the frh_get_table helper function never gets to do its job when
matching against current rule.
Use the helper function twice instead of peaking at the table value directly.

Originally reported at: http://bugs.debian.org/724783

Reported-by: Nicolas HICHER <nhicher@avencall.com>
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ravi Vembu <raviv@motorola.com>
Change-Id: Icdd6f8c17fa08e47a67b0706e172424fa21476b7
Reviewed-on: http://gerrit.mot.com/664039
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
[net-next commit bf439b3]

Change-Id: I8356e9132088c75d4510021c6e4c2641d772087a
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ravi Vembu <raviv@motorola.com>
Reviewed-on: http://gerrit.mot.com/664040
Submit-Approved: Jira Key <jirakey@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Currently, IPv6 router discovery always puts routes into
RT6_TABLE_MAIN. This causes problems for connection managers
that want to support multiple simultaneous network connections
and want control over which one is used by default (e.g., wifi
and wired).

To work around this connection managers typically take the routes
they prefer and copy them to static routes with low metrics in
the main table. This puts the burden on the connection manager
to watch netlink to see if the routes have changed, delete the
routes when their lifetime expires, etc.

Instead, this patch adds a per-interface sysctl to have the
kernel put autoconf routes into different tables. This allows
each interface to have its own autoconf table, and choosing the
default interface (or using different interfaces at the same
time for different types of traffic) can be done using
appropriate ip rules.

The sysctl behaves as follows:

- = 0: default. Put routes into RT6_TABLE_MAIN as before.
- > 0: manual. Put routes into the specified table.
- < 0: automatic. Add the absolute value of the sysctl to the
   device's ifindex, and use that table.

The automatic mode is most useful in conjunction with
net.ipv6.conf.default.accept_ra_rt_table. A connection manager
or distribution could set it to, say, -100 on boot, and
thereafter just use IP rules.

Change-Id: I093d39fb06ec413905dc0d0d5792c1bc5d5c73a9
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Ravi Vembu <raviv@motorola.com>
Reviewed-on: http://gerrit.mot.com/664041
Submit-Approved: Jira Key <jirakey@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
SLTApproved: Slta Waiver <sltawvr@motorola.com>

Conflicts:
	net/ipv6/route.c
Kernel-originated IP packets that have no user socket associated
with them (e.g., ICMP errors and echo replies, TCP RSTs, etc.)
are emitted with a mark of zero. Add a sysctl to make them have
the same mark as the packet they are replying to.

This allows an administrator that wishes to do so to use
mark-based routing, firewalling, etc. for these replies by
marking the original packets inbound.

Tested using user-mode linux:
- ICMP/ICMPv6 echo replies and errors.
- TCP RST packets (IPv4 and IPv6).

Change-Id: I95d896647b278d092ef331d1377b959da1deb042
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Ravi Vembu <raviv@motorola.com>
Reviewed-on: http://gerrit.mot.com/664042
Submit-Approved: Jira Key <jirakey@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
SLTApproved: Slta Waiver <sltawvr@motorola.com>

Conflicts:
	net/ipv6/tcp_ipv6.c
Mona Hossain and others added 24 commits April 21, 2015 01:07
Qseecom driver does not have boundary checks for offset within the
message. So this patch add checks to validate the offsets sent by
client to modify data within the command request message and it
should not exceed the memory allocated for that message.

Change-Id: I29bfbdc154eebb4f3f4bfbb31789562e37fa5886
Signed-off-by: Mona Hossain <mhossain@codeaurora.org>
Signed-off-by: Mallikarjuna Reddy Amireddy <mamire@codeaurora.org>
Improve user input validation across send cmd APIs. Add new
API  __validate_send_cmd_inputs() to validate all user provided
inputs.

Change-Id: Ibbb0c0e7e5483f653bd59b927562b63c1e43c365
Signed-off-by: Mona Hossain <mhossain@codeaurora.org>
Preload farther to take advantage of the memory bus, and assume
64-byte cache lines.  Unroll some pairs of ldm/stm as well, for
unexplainable reasons.

Future enhancements should include,

- #define for how far to preload, possibly defined separately for
  memcpy, copy_*_user
- Tuning for misaligned buffers
- Tuning for memmove
- Tuning for small buffers
- Understanding mechanism behind ldm/stm unroll causing some gains
  in copy_to_user

BASELINE (msm8960pro):
======================================================================
memcpy 1000MB at 5MB       : took 808850 usec, bandwidth 1236.236 MB/s
copy_to_user 1000MB at 5MB : took 810071 usec, bandwidth 1234.234 MB/s
copy_from_user 1000MB at 5M: took 942926 usec, bandwidth 1060.060 MB/s
memmove 1000GB at 5MB      : took 848588 usec, bandwidth 1178.178 MB/s
copy_to_user 1000GB at 4kB : took 847916 usec, bandwidth 1179.179 MB/s
copy_from_user 1000GB at 4k: took 935113 usec, bandwidth 1069.069 MB/s
copy_page 1000GB at 4kB    : took 779459 usec, bandwidth 1282.282 MB/s

THIS PATCH:
======================================================================
memcpy 1000MB at 5MB       : took 346223 usec, bandwidth 2888.888 MB/s
copy_to_user 1000MB at 5MB : took 348084 usec, bandwidth 2872.872 MB/s
copy_from_user 1000MB at 5M: took 348176 usec, bandwidth 2872.872 MB/s
memmove 1000GB at 5MB      : took 348267 usec, bandwidth 2871.871 MB/s
copy_to_user 1000GB at 4kB : took 377018 usec, bandwidth 2652.652 MB/s
copy_from_user 1000GB at 4k: took 371829 usec, bandwidth 2689.689 MB/s
copy_page 1000GB at 4kB    : took 383763 usec, bandwidth 2605.605 MB/s

Change-Id: I843fe77192d61ce35a81e75d76fc09f0a472e98a
Signed-off-by: Chris Fries <C.Fries@motorola.com>
1. To fit 8x26 64-bytes cache line size, we change preload steps as 64Bytes.
2. According to tune result, change preload distance as 5 cache lines.
3. According to tune result, re-arrange the ld/str order as back-to-back
   for copy_from_user.

The markable improvement:
	memcpy : 5%
	copy_to_user : 9%
	copy_from_user : 13%
	memmove : 37%

Raw data is as below:

BASELINE:
	memcpy 1000MB at 5MB       : took 1547098 usec, bandwidth 646.646 MB/s
	copy_to_user 1000MB at 5MB : took 1704308 usec, bandwidth 586.586 MB/s
	copy_from_user 1000MB at 5M: took 1777090 usec, bandwidth 562.562 MB/s
	memmove 1000GB at 5MB      : took 1066205 usec, bandwidth 937.937 MB/s
	copy_to_user 1000GB at 4kB : took 1774866 usec, bandwidth 563.563 MB/s
	copy_from_user 1000GB at 4k: took 1797654 usec, bandwidth 556.556 MB/s
	copy_page 1000GB at 4kB    : took 1644606 usec, bandwidth 608.608 MB/s
	memmove 1000GB at 4kB      : took 1236227 usec, bandwidth 808.808 MB/s

THIS PATCH:
	memcpy 1000MB at 5MB       : took 1475835 usec, bandwidth 677.677 MB/s
	copy_to_user 1000MB at 5MB : took 1559060 usec, bandwidth 641.641 MB/s
	copy_from_user 1000MB at 5M: took 1561603 usec, bandwidth 640.640 MB/s
	memmove 1000GB at 5MB      : took 861664 usec, bandwidth 1160.160 MB/s
	copy_to_user 1000GB at 4kB : took 1673501 usec, bandwidth 597.597 MB/s
	copy_from_user 1000GB at 4k: took 1674006 usec, bandwidth 597.597 MB/s
	copy_page 1000GB at 4kB    : took 1691358 usec, bandwidth 591.591 MB/s
	memmove 1000GB at 4kB      : took 882985 usec, bandwidth 1132.132 MB/s

Change-Id: I83bec3b7a9dd9cd88890eaa7ec423363e230a651
Signed-off-by: Hong-Mei Li <a21834@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/550383
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
According to tune result, change preload distance to 10
cache lines for 8974.
And considering bkk-b is sharing code for 8974, 8226, 8x16,
we seperate the code for 8974 specially.

The markable improvement:
    memcpy : 67%
    copy_to_user : 37%
    copy_from_user : 37%
    memmove : 70%

Raw data is as below:

BEFORE:
	memcpy 1000MB at 5MB       : took 659744 usec, bandwidth 1515.515 MB/s
	copy_to_user 1000MB at 5MB : took 681202 usec, bandwidth 1467.467 MB/s
	copy_from_user 1000MB at 5M: took 682052 usec, bandwidth 1466.466 MB/s
	memmove 1000GB at 5MB      : took 763133 usec, bandwidth 1310.310 MB/s
	copy_to_user 1000GB at 4kB : took 714487 usec, bandwidth 1399.399 MB/s
	copy_from_user 1000GB at 4k: took 699861 usec, bandwidth 1428.428 MB/s
	copy_page 1000GB at 4kB    : took 634857 usec, bandwidth 1575.575 MB/s
	memmove 1000GB at 4kB      : took 791389 usec, bandwidth 1263.263 MB/s
	memcpy 1000MB at 5MB       : took 659744 usec, bandwidth 1515.515 MB/s

AFTER:
	memcpy 1000MB at 5MB       : took 395178 usec, bandwidth 2530.530 MB/s
	copy_to_user 1000MB at 5MB : took 497667 usec, bandwidth 2009.009 MB/s
	copy_from_user 1000MB at 5M: took 496832 usec, bandwidth 2012.012 MB/s
	memmove 1000GB at 5MB      : took 449217 usec, bandwidth 2226.226 MB/s
	copy_to_user 1000GB at 4kB : took 489006 usec, bandwidth 2044.044 MB/s
	copy_from_user 1000GB at 4k: took 483982 usec, bandwidth 2066.066 MB/s
	copy_page 1000GB at 4kB    : took 377170 usec, bandwidth 2651.651 MB/s
	memmove 1000GB at 4kB      : took 483015 usec, bandwidth 2070.070 MB/s

Change-Id: I678d418b15701efea902efae9b94490993d53f37
Signed-off-by: Hong-Mei Li <a21834@motorola.com>
Reviewed-on: http://gerrit.mot.com/634422
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
SLTApproved: Christopher Fries <c.fries@motorola.com>
Reviewed-by: John Zafiris <johnz@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
When HAS_MACH_MEMUTILS is defined, two version of memcpy.S would
be built at the same time, fix the issue here.

Change-Id: Ia4e9604c45c04ffaad4f481ab454e8ee3c4a4d95
Signed-off-by: Hong-Mei Li <a21834@motorola.com>
Reviewed-on: http://gerrit.mot.com/629464
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
We used to read file_handle twice. Once to get the amount of extra bytes, and
once to fetch the entire structure.

This may be problematic since we do size verifications only after the first
read, so if the number of extra bytes changes in userspace between the first
and second calls, we'll have an incoherent view of file_handle.

Instead, read the constant size once, and copy that over to the final
structure without having to re-read it again.

Change-Id: Ib05e5129629e27d5a05953098c5bc470fae40d2a
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Some occurences in the netfilter tree use skb_header_pointer() in
the following way ...

  struct dccp_hdr _dh, *dh;
  ...
  skb_header_pointer(skb, dataoff, sizeof(_dh), &dh);

... where dh itself is a pointer that is being passed as the copy
buffer. Instead, we need to use &_dh as the forth argument so that
we're copying the data into an actual buffer that sits on the stack.

Currently, we probably could overwrite memory on the stack (e.g.
with a possibly mal-formed DCCP packet), but unintentionally, as
we only want the buffer to be placed into _dh variable.

Change-Id: Iac59a48fd2a86bb960d01b114ef02a896aa315be
Fixes: 2bc7804 ("[NETFILTER]: nf_conntrack: add DCCP protocol support")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
In order to use the NEON unit in the kernel, we should
initialize it a bit earlier in the boot process so NEON users
that like to do a quick benchmark at load time (like the
xor_blocks or RAID-6 code) find the NEON/VFP unit already
enabled.

Replaced late_initcall() with core_initcall().

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
The timeout entries are sizeof(int) rather than sizeof(long), which
means that when they were getting read we'd also leak kernel memory
to userspace along with the timeout values.

Change-Id: I328d1186720a6f70f555eeeb62c83ee69814868d
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A local route may have a lower hop_limit set than global routes do.

RFC 3756, Section 4.2.7, "Parameter Spoofing"

>   1.  The attacker includes a Current Hop Limit of one or another small
>       number which the attacker knows will cause legitimate packets to
>       be dropped before they reach their destination.

>   As an example, one possible approach to mitigate this threat is to
>   ignore very small hop limits.  The nodes could implement a
>   configurable minimum hop limit, and ignore attempts to set it below
>   said limit.

Change-Id: I51ee1778e3d2d5fa1aefbdf1ad8869e4e8dc28b2
Signed-off-by: D.S. Ljungmark <ljungmark@modio.se>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Include <linux/types.h> into ashmem.h to ensure referenced types are defined

Signed-off-by: Rom Lemarchand <romlem@android.com>
Change-Id: If82d92caa6c148ab2182a681637fc8e17c44346d
Sasha Levin found a NULL pointer dereference that is due to a missing
page table lock, which in turn is due to the pmd entry in question being
a transparent huge-table entry.

The code - introduced in commit 1998cc0 ("mm: make
madvise(MADV_WILLNEED) support swap file prefetch") - correctly checks
for this situation using pmd_none_or_trans_huge_or_clear_bad(), but it
turns out that that function doesn't work correctly.

pmd_none_or_trans_huge_or_clear_bad() expected that pmd_bad() would
trigger if the transparent hugepage bit was set, but it doesn't do that
if pmd_numa() is also set. Note that the NUMA bit only gets set on real
NUMA machines, so people trying to reproduce this on most normal
development systems would never actually trigger this.

Fix it by removing the very subtle (and subtly incorrect) expectation,
and instead just checking pmd_trans_huge() explicitly.

Reported-by: Sasha Levin <sasha.levin@oracle.com>
Acked-by: Andrea Arcangeli <aarcange@redhat.com>
[ Additionally remove the now stale test for pmd_trans_huge() inside the
  pmd_bad() case - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Change-Id: I3f3763f236ef102de735297cd175cf514d40d28f
Add RT priority to KTM frequency mitigation thread. This
is required since we have seen cases where this thread
is not scheduled fast enough during high temperature rampup
that lead to thermal runaway. So this change would make sure
the thermal frequency mitigation thread gets high priority
and mitigate core as soon as a temperature threshold is triggered.

Change-Id: Ie8a6fd80fb8e9bdb894a26a8bf7abd159a3f3bce
Signed-off-by: Shiju Mathew <shijum@codeaurora.org>
Optimize locking in thermal frequency mitigation thread
to reduce lock contention with hotplug mitigation thread.
This lock is not explicitly required since the cpu driver
already have a per cluster lock down the freqency mitigation
call path. This would be much optimized since the new changes
will hold the lock for a shorter period and unlike previously
where the lock was for entire cluster, this is per cluster
lock that will further reduce lock contention. This would
help thermal to do mitigation faster.

Change-Id: I192efa77df8ad9b128759f31300d4a64a558cc16
Signed-off-by: Shiju Mathew <shijum@codeaurora.org>
Add RT priority to KTM hotplug mitigation thread. This
is required since we have seen cases where the thread
is not scheduled fast enough during high temperature rampup
that lead to thermal runaway. So this change would make sure
the thermal hotplug mitigation thread gets high priority
and mitigate core as soon as a temperature threshold is triggered.

Change-Id: I72ecf69ede0444fe74fd9c4eaf40a12e8734326c
Signed-off-by: Shiju Mathew <shijum@codeaurora.org>
"timer" was checked for null, but used later without being re-checked.

Change-Id: Ib4d08cd49860c9f157d1cac556705ba85cd44f4e
Reported-by: dan.carpenter@oracle.com
Signed-off-by: JP Abgrall <jpa@google.com>
… with simple warnings

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Whenever vidc device is required to move from INIT state to CLOSE state,
device state moves to INVALID state. For every state trasition there is a
call to get_flipped_state() routine, this routine validates target state
before actual transition. Due to safegaurding logic for target state in
routine get_flipped_state(), transition from INIT to CLOSE stae does not
happen and target state becomes INVALID state. From INVALID state device
can not be closed/unloaded and clock will be held on. As a part of fix,
change is done for graceful closure and unloading of device whenever device
is in INVALID state.

Change-Id: I8d69ce2ec7bcd76b1f384808bedaec21c66df5f5
Signed-off-by: c_sridur <sridur@codeaurora.org>
If sensor probe fails VIDIOC_MSM_SENSOR_INIT_CFG ioctl is
blocking, so modifying wait_event_interruptible call to
wait_event_interruptible_timeout.

Change-Id: Icf6522d01e97c7a154177b88f7161cdf65c7d9eb
CRs-Fixed: 666077
Signed-off-by: Katta Santhisindhu <kattas@codeaurora.org>
When hardware is overloaded or when max number of clients are
reached in driver or firmware, hardware error is sent to video
client. This change is to replace hardware error with actual
errors.

CRs-fixed: 575852
Change-Id: I07e599f894a3716a3dc4fed5eb7c987311f5bdde
Signed-off-by: Deepak Verma <dverma@codeaurora.org>
@ivan19871002
Copy link
Member

I create a new branch lollipop-mr1 , that is can be used

@ajitkatte
Copy link
Author

Yes, I created merge request for wrong branch.

On Sat, May 16, 2015, 12:00 PM 秋叶随风ivan notifications@github.com wrote:

I create a new branch lollipop-mr1 , that is can be used


Reply to this email directly or view it on GitHub
#1 (comment)
.

@ajitkatte ajitkatte closed this May 16, 2015
@PepeII
Copy link

PepeII commented May 22, 2015

Which version GCC and Cross Compiler Toolchain do you use? I am not able to compile your kernel with GCC 4.9 and Linaro 4.9.3

@ajitkatte
Copy link
Author

I'm using Linaro 4.9.3 and I am able to compile the kernel souces
flawlessly.

On Fri, May 22, 2015, 10:35 AM PepeII notifications@github.com wrote:

Which version GCC and Cross Compiler Toolchain do you use? I am no able to
compile your kernel with GCC 4.9 and Linaro 4.9.3


Reply to this email directly or view it on GitHub
#1 (comment)
.

@audahadi audahadi deleted the cm-12.1 branch June 7, 2015 19:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.