arm64: dts: qcom: msm8916/39-samsung-a2015/fortuna/serranove: Add flash LED #327
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wonderfulShrineMaidenOfParadise
force-pushed
the
rt5033-led
branch
from
b53c4d7
to
0c42ec4
Compare
wonderfulShrineMaidenOfParadise
changed the base branch from
msm8916/6.5-rc7
to
msm8916/6.5.2
wonderfulShrineMaidenOfParadise
force-pushed
the
rt5033-led
branch
from
0c42ec4
to
b5d033a
Compare
wonderfulShrineMaidenOfParadise
force-pushed
the
rt5033-led
branch
from
b5d033a
to
a180395
Compare
wonderfulShrineMaidenOfParadise
changed the base branch from
msm8916/6.5.2
to
wip/msm8916/6.9
TravMurav
force-pushed
the
wip/msm8916/6.9
branch
from
c4d3662
to
e7a0931
Compare
Add #define STMFTS_RETRY_COUNT 3 to retry stmfts_command() 3 times. Without it, STMFTS_SYSTEM_RESET or STMFTS_SLEEP_OUT may return -110 to failed attempt due to no event received for completion. Signed-off-by: Lin, Meng-Bo <[email protected]> Reviewed-by: Mattijs Korpershoek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
…prev_first For a given bridge pipeline if any bridge sets pre_enable_prev_first flag then the pre_enable for the previous bridge will be called before pre_enable of this bridge and opposite is done for post_disable. These are the potential bridge flags to alter bridge init order in order to satisfy the MIPI DSI host and downstream panel or bridge to function. However the existing pre_enable_prev_first logic with associated bridge ordering has broken for both pre_enable and post_disable calls. [pre_enable] The altered bridge ordering has failed if two consecutive bridges on a given pipeline enables the pre_enable_prev_first flag. Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first. The logic looks for a bridge which enabled pre_enable_prev_first flag on each iteration and assigned the previou bridge to limit pointer if the bridge doesn't enable pre_enable_prev_first flags. If control found Bridge 2 is pre_enable_prev_first then the iteration looks for Bridge 3 and found it is not pre_enable_prev_first and assigns it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3 and Bridge 2 and assign iter pointer with limit which is Bridge 4. Here is the actual problem, for the next iteration control look for Bridge 5 instead of Bridge 4 has iter pointer in previous iteration moved to Bridge 4 so this iteration skips the Bridge 4. The iteration found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned to Encoder. From next iteration Encoder skips as it is the last bridge for reverse order pipeline. So, the resulting pre_enable bridge order would be, - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5. This patch fixes this by assigning limit to next pointer instead of previous bridge since the iteration always looks for bridge that does NOT request prev so assigning next makes sure the last bridge on a given iteration what exactly the limit bridge is. So, the resulting pre_enable bridge order with fix would be, - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. [post_disable] The altered bridge ordering has failed if two consecutive bridges on a given pipeline enables the pre_enable_prev_first flag. Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder In this example Bridge 5 and Bridge 4 have pre_enable_prev_first. The logic looks for a bridge which enabled pre_enable_prev_first flags on each iteration and assigned the previou bridge to next and next to limit pointer if the bridge does enable pre_enable_prev_first flag. If control starts from Bridge 6 then it found next Bridge 5 is pre_enable_prev_first and immediately the next assigned to previous Bridge 6 and limit assignments to next Bridge 6 and call post_enable of Bridge 6 even though the next consecutive Bridge 5 is enabled with pre_enable_prev_first. This clearly misses the logic to find the state of next conducive bridge as everytime the next and limit assigns previous bridge if given bridge enabled pre_enable_prev_first. So, the resulting post_disable bridge order would be, - Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1, Panel. This patch fixes this by assigning next with previou bridge only if the bridge doesn't enable pre_enable_prev_first flag and the next further assign it to limit. This way we can find the bridge that NOT requested prev to disable last. So, the resulting pre_enable bridge order with fix would be, - Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1, Panel. Validated the bridge init ordering by incorporating dummy bridges in the sun6i-mipi-dsi pipeline Fixes: 4fb912e ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order") Signed-off-by: Jagan Teki <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Zinitix touch controllers can use some of the sense lines for virtual keys (like those found on many phones). Add support for those keys. Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Nikita Travkin <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Add a simple driver for the Himax HX852x(ES) touch panel controller, with support for multi-touch and capacitive touch keys. The driver is somewhat based on sample code from Himax. However, that code was so extremely confusing that we spent a significant amount of time just trying to understand the packet format and register commands. In this driver they are described with clean structs and defines rather than lots of magic numbers and offset calculations. Signed-off-by: Jonathan Albrieux <[email protected]> Co-developed-by: Stephan Gerhold <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]> Reviewed-by: Jeff LaBundy <[email protected]> Link: https://lore.kernel.org/r/[email protected]
TravMurav
force-pushed
the
wip/msm8916/6.9
branch
from
e7a0931
to
903e6f0
Compare
wonderfulShrineMaidenOfParadise
force-pushed
the
rt5033-led
branch
from
a180395
to
64d98dc
Compare
Enable sound and modem for Acer Iconia Talk S A1-724. The setup is similar to most MSM8916 devices, i.e.: - QDSP6 audio - Earpiece/headphones/microphones via digital/analog codec in MSM8916/PM8916 - WWAN Internet via BAM-DMUX Signed-off-by: Raymond Hackley <[email protected]> Link: https://lore.kernel.org/r/[email protected]
TravMurav
force-pushed
the
wip/msm8916/6.9
branch
from
19cb01e
to
349abab
Compare
wonderfulShrineMaidenOfParadise
force-pushed
the
rt5033-led
branch
from
64d98dc
to
6048f27
Compare
protocol_b is a property, which tells Imagis panel to use a different format for coordinates. IST30XXC series is known for using protocol B, while the other series aren't. Note this could be confusing, unlike the model name implies. Adjust the usage of protocol_b to avoid confusion. Signed-off-by: Raymond Hackley <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]
Imagis IST3038 is a variant of Imagis touchscreen IC. Document it in imagis,ist3038c bindings. Signed-off-by: Raymond Hackley <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]
Imagis IST3038 is another variant of Imagis IST3038 IC, which has a different register interface from IST3038C (possibly firmware defined). Unlike IST3038C/IST3032C, IST3038 has different registers for commands, which means IST3038 doesn't use protocol B. Similar to IST3032C and maybe the other variants, IST3038 has touch keys support, which provides KEY_APPSELECT and KEY_BACK. Add support for IST3038 with touch keys. Signed-off-by: Raymond Hackley <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]
In DSI video mode the video stream should not be active yet when the panel pre_enable() hook is called. However this is impossible currently because the DSI host is powered up and started in the same bridge pre_enable() hook. Split this into pre_enable() and enable() and start the video stream only during enable(), after the panel pre_enable() has already run. Same for disable()/post_disable(). Fixes: 007ac02 ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE") Signed-off-by: Stephan Gerhold <[email protected]>
For some reason the mdp5 encoder must be started after the DSI video stream is active, otherwise there is just an endless spam of [ 11.686336] dsi_err_worker: 4440 callbacks suppressed [ 11.686351] dsi_err_worker: status=5 [ 11.686382] dsi_err_worker: status=4 [ 11.686407] dsi_err_worker: status=4 [ 11.686427] dsi_err_worker: status=4 ... There does not seem to be a good encoder hook to use this at the moment, so introduce some temporary hacks to delay the existing callback. Signed-off-by: Stephan Gerhold <[email protected]>
Signed-off-by: Stephan Gerhold <[email protected]>
Some Synaptics touchscreens with F12 do not seem to report pressure (z) information. Unfortunately, in this case the "z" field is missing in the data, causing the width and all further objects to be shifted by one byte. Also, there seems to be no way to detect this dynamically because the RMI item register description still says there are 8 bytes for each finger/object, even though there are only 7 in this case. Make it possible to use those touchscreens properly by adding a "syna,no-pressure"+"syna,no-width" property for the DT and use that to handle the data correctly. Signed-off-by: Stephan Gerhold <[email protected]>
The interconnects should be added to all components of the SoC at once, i.e. SDHCI, USB, MDSS, ... Otherwise the bandwidth might be reduced too much when MDP is inactive/disabled because all other components only work as a side effect of the bandwidth votes from MDP. Signed-off-by: Stephan Gerhold <[email protected]>
Add an initial device tree for MSM8909 (Snapdragon 210), based mostly on the existing msm8916.dtsi. v2: Use separate nvmem cells for tsens v3: Move WCNSS iris compatible to boards v4: align TLMM pin configuration with DT schema v5: Make blsp_dma qcom,controlled-remotely v6: Fix a7pll frequencies v7: Squash cpufreq additions Co-developed-by: Dominik Kobinski <[email protected]> Signed-off-by: Dominik Kobinski <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]>
Taken mostly from pm8916.dtsi. v2: Add watchdog v3: Add RTC v4: Add MPPs/GPIOs/PWM/Vibrator Signed-off-by: Stephan Gerhold <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]>
Signed-off-by: Otto Pflüger <[email protected]> v2: Update for upstream driver
The msm8909-pm8909.dtsi include configures the regulator supplies of MSM8909 used together with PM8909, as recommended by Qualcomm. In rare cases where boards deviate from the recommended design they can just avoid using this include. Signed-off-by: Stephan Gerhold <[email protected]>
It's not clear why it happens but some WCN3620 firmwares seem to occasionally seems to send scan packets with rf_band = 0, which is currently interpreted like 5 GHz band. This causes big WARNINGs later because those bands are not initialized for WCN3620: WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:4877 ieee80211_rx_list+0x488/0xa10 [mac80211] Hardware name: Samsung Galaxy Grand Prime (SM-G530H) (DT) pc : ieee80211_rx_list+0x488/0xa10 [mac80211] lr : ieee80211_rx_napi+0x58/0xe0 [mac80211] Call trace: ieee80211_rx_list+0x488/0xa10 [mac80211] ieee80211_rx_napi+0x58/0xe0 [mac80211] ieee80211_tasklet_handler+0xe4/0xf0 [mac80211] ... Let's skip the check for WCN3620 for now and warn only once to avoid spam in the kernel log. Signed-off-by: Stephan Gerhold <[email protected]>
v2: Make reset-gpios GPIO_ACTIVE_LOW
v3: Add &mdss { status = "okay"; };
Signed-off-by: Markuss Broks <[email protected]>
v4: Move from msm8916-samsung-j5
Signed-off-by: Lin, Meng-Bo <[email protected]>
Add regulators for the panel on J3. Note that l17 is required. Signed-off-by: Lin, Meng-Bo <[email protected]>
Signed-off-by: Lin, Meng-Bo <[email protected]>
J3 and J5X use an Imagis IST3038C touchscreen that is connected to blsp_i2c5. Add it to the device tree. Regulator and MFD drivers for SM5703 are unavailable at the moment, which is required to power up the touchscreen on J5, so it's disabled on J5 for now. Signed-off-by: Lin, Meng-Bo <[email protected]>
Signed-off-by: Lin, Meng-Bo <[email protected]> v4: Split from common commit after j5 upstreaming Signed-off-by: Stephan Gerhold <[email protected]>
…tection (v2) v2: Moved from msm8916-samsung-j5x Headset microphone is broken with this on j5x, headphone buttons are broken as well. (Needs more investigation...) Signed-off-by: Lin, Meng-Bo <[email protected]>
E7 uses a ST-Microelectronics FingerTip touchscreen that is connected to blsp_i2c5. Add it to the device tree. v2: Add suffix "-state" to pinctrl. Signed-off-by: Lin, Meng-Bo <[email protected]>
v2: Add suffix "-state" to pinctrl. Signed-off-by: Lin, Meng-Bo <[email protected]>
Signed-off-by: "Lin, Meng-Bo" <[email protected]>
Grand Max uses an Imagis IST3038 touchscreen that is connected to blsp_i2c5. Add it to the device tree. Signed-off-by: "Lin, Meng-Bo" <[email protected]> v2: Add touch keys Signed-off-by: Raymond Hackley <[email protected]>
v2: Set &mdss_dsi0 and &mdss_dsi0_phy with status = "okay"; v3: adapted for current msm8939.dtsi (mdss_dsi0 and mdss_dsi0_phy) [vknecht: adapted for current msm8939.dtsi (mdss_dsi0 and mdss_dsi0_phy)] v4: adapted for current msm8939.dtsi (dsi0 and dsi_phy0) Add suffix "-state" to pinctrl. Put status = "okay"; at the end of the properties v5: Add missed status for the dsi phy Signed-off-by: "Lin, Meng-Bo" <[email protected]>
v2: Add suffix "-state" to pinctrl. Signed-off-by: Lin, Meng-Bo <[email protected]>
Add support for SMB1360 fuel gauge & charger circuit. Signed-off-by: Vincent Knecht <[email protected]> v2: Increase timeout to 768 Signed-off-by: Jakob Hauser <[email protected]>
Signed-off-by: Otto Pflüger <[email protected]>
Signed-off-by: Otto Pflüger <[email protected]>
Signed-off-by: André Apitzsch <[email protected]> v4: split from initial commit after upstreaming Signed-off-by: Stephan Gerhold <[email protected]>
Signed-off-by: André Apitzsch <[email protected]>
Add support for SMB1360 fuel gauge and charger circuit. Signed-off-by: André Apitzsch <[email protected]> v2: Increase timeout to 768 Signed-off-by: Jakob Hauser <[email protected]>
Signed-off-by: Adam Słaboń <[email protected]>
Signed-off-by: Adam Słaboń <[email protected]>
Signed-off-by: Lin, Meng-Bo <[email protected]>
Signed-off-by: Raymond Hackley <[email protected]>
Signed-off-by: Raymond Hackley <[email protected]>
TravMurav
force-pushed
the
wip/msm8916/6.9
branch
from
224cef4
to
f8e8fc2
Compare
The phones listed below have Richteck RT5033 LED, which has GPIO pin configurations similar to SGM3140 Flash LED driver. Add it to the device trees. - Samsung Galaxy A3/A5/A7 2015 - Samsung Galaxy E5/E7 - Samsung Galaxy Grand Max Signed-off-by: Raymond Hackley <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/
The phones listed below have Richteck RT5033 LED, which has GPIO pin configurations similar to SGM3140 Flash LED driver. Add it to the device trees. - Samsung Galaxy Ace 4 - Samsung Galaxy Core Prime LTE - Samsung Galaxy Grand Prime Signed-off-by: Raymond Hackley <[email protected]>
Samsung Galaxy S4 Mini VE has Richteck RT5033 LED, which has GPIO pin configurations similar to SGM3140 Flash LED driver. Add it to the device tree. Signed-off-by: Raymond Hackley <[email protected]>
wonderfulShrineMaidenOfParadise
force-pushed
the
rt5033-led
branch
from
6048f27
to
cfa51ac
Compare
TravMurav
force-pushed
the
wip/msm8916/6.9
branch
from
eb39f23
to
fc59a46
Compare
TravMurav
force-pushed
the
wip/msm8916/6.9
branch
from
77359bc
to
f1299dc
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Redo #317