-
Notifications
You must be signed in to change notification settings - Fork 364
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
[7.1.r1][DNM] Add missing commits from LA.UM.7.1.r1-16600-sm8150.0 #2330
base: aosp/LA.UM.7.1.r1
Are you sure you want to change the base?
[7.1.r1][DNM] Add missing commits from LA.UM.7.1.r1-16600-sm8150.0 #2330
Conversation
Aaaahhhhh! Empty commit! Ahhhhh my eyes! :D Also, one specific test is necessary here:
Please execute this test on both old (Yoshino) and new (Tama or Kumano) platforms before merging this. |
bf5da44
to
8fcdb20
Compare
Tested it on yoshino/lilac:
Should be this from the kernel.log:
A sidenote, when removing the tray. A message pops up: "SIM card has been removed", and when re-inserting the tray a message "SIM card has been added" is shown. Those messages have been coming as well before this PR. However the removal of the tray does not remove the SIM card. but only the microsd. From my point of view the test was successful on yoshino/lilac. |
6976538
to
aa7af71
Compare
8892453
to
4f7cfde
Compare
aa7af71
to
ac33101
Compare
The esoc framework notifies MHI of a device assert using early hooks. As part of moving MHI to an error state, wake up any waiting threads so they can bail out early. CRs-Fixed: 2500104 Change-Id: I8bf9b085cef078f0692ad198ca1ba2a8149c3172 Acked-by: Bhaumik Vasav Bhatt <[email protected]> Signed-off-by: Sujeev Dias <[email protected]>
PCI devices with no_d3hot set do not need its configuration space restored in pci_pm_resume. Change-Id: Ia92f5278bfbd35d082fce53d9b2de9397a69b942 Signed-off-by: Tony Truong <[email protected]>
Some of user space daemon like ADB queries endpoint descriptor using ioctl to know wMaxPacketSize value. Based on wMaxPacketSize value it queues additional buffer to read zero length packet if expected read buffer size is multiple of wMaxPacketSize. Currently driver is missing handling for super speed plus case which results into sending full speed related USB endpoint descriptor (i.e. wMaxPacketSize 64 bytes). Hence when adbd is expecting 64 bytes packet from host, it queues one more additional buffer. This results into mismatch of ADB command and response when multiple ADB commands are used and causing different ADB related stability issues. Fix this issue adding super speed plus check with FUNCTIONFS_ENDPOINT_DESC ioctl command. Change-Id: I9416295c07c2d98f9d32df43d7e506f975da15a2 Signed-off-by: Mayank Rana <[email protected]>
dpdm_regulator_enable() function turn on the CXO clk to program the phy registers to put PHY in non-driving mode for charger detection. In charger connected case phy driver voting for CXO clock in dpdm_regulator_enable but does not disabling it which is preventing the system from vdd minimization. Hence fix this issue by turning off the CXO clk from dpdm_regulator_enable. Change-Id: Ib3a04eedcef625443077199d5920884f114db82d Signed-off-by: Chandana Kishori Chiluveru <[email protected]>
Update SD card removal event processing logic. Instead of pinging the card to know the card presence rely on card-detect gpio state. On multi-card tray designs, the same card-tray would be used for SD card and SIM cards. If SD card is placed at the rightmost location in the tray, then SIM card may come in contact with SD card power- supply while removing the tray. It may result in SIM damage. For protecting SIM from this issue, in multi-card tray designs, a h/w fix done such that pmic gets a notification of SD card removal event (through hardwiring) and it turns off the SD card voltage regulators immediately. All this will be done much before SD card driver starts processing card removal event. To support this design, SD card driver shouldn't turn-on the regulator while processing card removal event. But the present mmc driver turns-on regulator (multiple times if the card was in suspend state). To avoid turning on SD card regulator in card removal path, updating the card removal processing logic is based on card detect gpio state. Change-Id: I13708a60c9378519713ebec8071ae3b130012a93 Signed-off-by: Veerabhadrarao Badiganti <[email protected]> Signed-off-by: Sarthak Garg <[email protected]>
This reverts commit 9de18ca. Reverting this change as this is introducing race condition with sdcard plug out scenario and leading to device crash. 1. Deferred resume kicks in 2. SDCard is plugged out 3. Deferred resume failed 4. SDCard detection scheduled as resume fails 5. Device crashing Change-Id: I6fd81d6c21be4a0e3139246c9d66959010fd240c Signed-off-by: Ram Prakash Gupta <[email protected]> Signed-off-by: Sarthak Garg <[email protected]>
If resume fails, there is no way to handle it now. Also there's no attempt to recover from it. This leads to lot of warnings while issuing requests. Check for resume errors & reset the stack on error as an attempt to recover from it. Change-Id: Ie4d6d2a34c2c7a8154696e93d85e50d60410e0c2 Signed-off-by: Asutosh Das <[email protected]> Signed-off-by: Ram Prakash Gupta <[email protected]> Signed-off-by: Sarthak Garg <[email protected]>
Sometimes when the card is removed and a request is in queue the resume fails. But there's no way to inform the in-flight request that the card is removed since the resume itself fails and rescan is waiting for claim_host which was acquired by the in-flight request. This request percolates to platform driver which sees that the pre-requisites to issue the request are not met i.e. the clocks are OFF. So it tries to dump the registers and results in a NoC error. Set the card removed when resume fails to avoid this problem. CRs-fixed: 2430862 Change-Id: I171ad435ec11c1212e6528592b8db43cd0171b11 Signed-off-by: Asutosh Das <[email protected]> Signed-off-by: Ram Prakash Gupta <[email protected]> Signed-off-by: Sarthak Garg <[email protected]>
The read was introduced with commit ID: 8e8bb1a and it is a leftover from cherry picking the commit with the ID: e8c6f4c. Signed-off-by: Stefan Rücker <[email protected]>
Camera CAMNOC, ICP, IPE, BPS, CDM, SMMU, JPEG, IFE, PPI nodes are added for chipsets having v150_110 camera. Change-Id: Iea631ba2f7a48fa1a144769097acdc865cfbbbdc Signed-off-by: Chandan Kumar Jha <[email protected]>
PPI clock sources are added for chipsets having v150_110 camera. Change-Id: Ibab7f009fce45ea309f13501efb2f16fafb87ed6 Signed-off-by: Chandan Kumar Jha <[email protected]>
AHB-IB bandwidth are added for chipsets having v150_110 camera. Change-Id: I6df5d35fa5c9bf2f7b056f9f5333147c3564fa00 Signed-off-by: Chandan Kumar Jha <[email protected]>
Add CCI,CSIPHY hardware nodes, clocks, gpios to control the camera sensors for atoll. Change-Id: I6f2272070941686c06ec52d964a968123ce6ded5 Signed-off-by: Shankar Ravi <[email protected]>
Enable and add csiphy regulators in csiphy nodes for atoll. Change-Id: Ic394ee0be86fb1b0cba8a51a8b134eb426681c78 Signed-off-by: Shravan Nevatia <[email protected]>
Add sensor, actuator, eeprom and flash nodes for atoll Change-Id: I754c9396dae6d2635bd092ca816591f956624076 Signed-off-by: Shravan Nevatia <[email protected]>
ac33101
to
5ec379b
Compare
The commits regarding camera probably don't affect any Sony device or do they? |
@kholk @stefanhh0 What kind of changes are left in this tree that can improve sm8150 support? |
1aa2204
to
838a06e
Compare
A cherry-pick PR to have all commits included that are in:
https://source.codeaurora.org/quic/la/kernel/msm-4.14/tag/?h=LA.UM.7.1.r1-16600-sm8150.0
Please review and test. This PR is already running on Yoshino/Lillac without any problems.
See especially: bf5da44. This is an idea how to identify what we have merged back via cherry-picking. Please provide feedback.I have also included the camera commits, since all of them are just about adding the atoll cam, thus I believe it can be merged back together with the other changes and should not affect the other cameras we are already using.
Additionally I have created the special commit 1fcd973 the removes a remnant. I think that is a pretty harmless cleanup.
This PR supersedes: #2327 and #2156 in consequence those should just be closed and not merged back.