- Jun 06, 2024
-
-
Dmitry Baryshkov authoredEnable support for the GPU Clock Controller for the Qualcomm SM8350 platform. This enables the GPU on Qualcomm SM8350 HDK and other devices using this SoC. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240530-8350-config-v1-1-d6e871236ed4@linaro.org Signed-off-by:
Bjorn Andersson <andersson@kernel.org>
-
Enable the Qualcomm SM8350 LPASS TLMM pin controller driver for providing GPIOs/pins for audio block on SM8350 based boards (e.g. HDK8350). Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230719192058.433517-3-krzysztof.kozlowski@linaro.org Signed-off-by:
-
Enable GPU Clock Controller for SM8450 and SM8550 to allow using Adreno GPU on these SoCs. Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231218-topic-sm8x50-upstream-gpucc-defconfig-v2-1-e5892470a10b@linaro.org Signed-off-by:
-
- Jun 03, 2024
-
-
Dmitry Baryshkov authored
On the Qualcomm RB2 platform the I2C bus connected to the LT9611UXC bridge under some circumstances can go into a state when all transfers timeout. This causes both issues with fetching of EDID and with updating of the bridge's firmware. While we are debugging the issue, switch corresponding I2C bus to use i2c-gpio driver. With this driver no communication issues are observed. This patch is asusmed to be a temporary fix, so it is implemented in a non-intrusive manner to simply reverting it later. Signed-off-by: -
Dmitry Baryshkov authored
On the Qualcomm RB1 platform the I2C bus connected to the LT9611UXC bridge under some circumstances can go into a state when all transfers timeout. This causes both issues with fetching of EDID and with updating of the bridge's firmware. While we are debugging the issue, switch corresponding I2C bus to use i2c-gpio driver. With this driver no communication issues are observed. This patch is asusmed to be a temporary fix, so it is implemented in a non-intrusive manner to simply reverting it later. Signed-off-by: -
Dmitry Baryshkov authored
The L9A regulator is used to further control voltage regulators on the board. Make sure that is stays always on to prevent undervolting some of the volage rails. Signed-off-by: -
Dmitry Baryshkov authored
This reverts commit 34f063d4.
-
Dmitry Baryshkov authored
This reverts commit f8bd72e3.
-
For i2c read operation in GSI mode, we are getting timeout due to malformed TRE basically incorrect TRE sequence in gpi(drivers/dma/qcom/gpi.c) driver. I2C driver has geni_i2c_gpi(I2C_WRITE) function which generates GO TRE and geni_i2c_gpi(I2C_READ)generates DMA TRE. Hence to generate GO TRE before DMA TRE, we should move geni_i2c_gpi(I2C_WRITE) before geni_i2c_gpi(I2C_READ) inside the I2C GSI mode transfer function i.e. geni_i2c_gpi_xfer(). TRE stands for Transfer Ring Element - which is basically an element with size of 4 words. It contains all information like slave address, clk divider, dma address value data size etc). Mainly we have 3 TREs(Config, GO and DMA tre). - CONFIG TRE : consists of internal register configuration which is required before start of the transfer. - DMA TRE : contains DDR/Memory address, called as DMA descriptor. - GO TRE : contains Transfer directions, slave ID, Delay flags, Length of the transfer. I2c driver calls GPI driver API to config each TRE depending on the protocol. For read operation tre sequence will be as below which is not aligned to hardware programming guide. - CONFIG tre - DMA tre - GO tre As per Qualcomm's internal Hardware Programming Guide, we should configure TREs in below sequence for any RX only transfer. - CONFIG tre - GO tre - DMA tre Fixes: d8703554 ("i2c: qcom-geni: Add support for GPI DMA") Reviewed-by:Andi Shyti <andi.shyti@kernel.org> Reviewed-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # qrb5165-rb5 Co-developed-by:
Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> Signed-off-by:
Viken Dadhaniya <quic_vdadhani@quicinc.com> Reviewed-by:
-
- Jun 02, 2024
-
-
Dmitry Baryshkov authored
Enable drivers for interconnects on Qualcomm MSM8996 (Dragonboard 820c), SM8150 (SM8150 HDK), SM8350 (SM8350 HDK) to be built-in. Otherwise boot time issues are observed on these platforms. Signed-off-by: -
Dmitry Baryshkov authored
In attempt to fix the I2C transfer issues, lower the bus speed from 400 kHz to 100 kHz. Signed-off-by: -
Dmitry Baryshkov authored
In attempt to fix the I2C transfer issues, lower the bus speed from 400 kHz to 100 kHz. Signed-off-by:
-
- Jun 01, 2024
-
-
The Qualcomm UFS phy switched from dedicated driver to QMP phy driver. Eventually the old driver was removed in commit 02dca8c9 ("phy: qcom: remove ufs qmp phy driver"). The original driver and its binding used vddp-ref-clk regulator supply, but the new one did not and left the supply unused. The Qualcomm UFS phy bindings were also migrated to newer ones and dropped support for vddp-ref-clk regulator in commit dc5cb635 ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml"). It turns out that this regulator, although with inaccurate name vddp-ref-clk, is actually needed to provide supply for VDD_PX10 (or similar, depending on the SoC) used by UFS controller. Bring back handling of this supply by using more appropriate regulator - UFS controller host supply. This also fixes dtbs_check warning: apq8096-db820c.dtb: phy@627000: 'vddp-ref-clk-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905161920.252013-6-krzysztof.kozlowski@linaro.org Signed-off-by:
-
Some nodes may have different coefficients than the general values for bus they're attached to. Check for that and use them if present. See [1], [2] for reference. [1] https://github.com/sonyxperiadev/kernel/commit/7456d9779af9ad6bb9c7ee6f33d5c5a8d3648e24 [2] https://github.com/artem/android_kernel_sony_msm8996/commit/bf7a8985dcaf0eab5bc2562d2d6775e7e29c0f30 Signed-off-by:
Georgi Djakov <djakov@kernel.org>
-
If this hardware couldn't get messier, some nodes are supposed to drive their own bus clock.. Presumably to connect to some intermediate interface between the node itself and the bus it's (supposed to be) connected to. Expand the node struct with the necessary data and hook up the allocations & calculations. Note that the node-specific AB/IB coefficients contribute (by design) to both the node-level and the bus-level aggregation. Signed-off-by:
-
In preparation for also setting per-node clock rates, separate out the logic that computes it. Signed-off-by:
-
Presumably due to the hardware being so complex, some nodes (or busses) have different (usually higher) requirements for bandwidth than what the usual calculations would suggest. Looking at the available downstream files, it seems like AB values are adjusted per-bus and IB values are adjusted per-node. With that in mind, introduce percentage-based coefficient struct members and use them in the calculations. One thing to note is that the IB coefficient is inverse (100/ib_percent) which feels a bit backwards, but it's necessary for precision.. Signed-off-by:
-
Dmitry Baryshkov authored
Add missing coefficient for the BIMC NoC. Signed-off-by: -
When typec_altmode_put_partner is called by a plug altmode upon release, the port altmode the plug belongs to will not remove its reference to the plug. The check to see if the altmode being released is a plug evaluates against the released altmode's partner instead of the calling altmode, so change adev in typec_altmode_put_partner to properly refer to the altmode being released. Because typec_altmode_set_partner calls get_device() on the port altmode, add partner_adev that points to the port altmode in typec_put_partner to call put_device() on. typec_altmode_set_partner is not called for port altmodes, so add a check in typec_altmode_release to prevent typec_altmode_put_partner() calls on port altmode release. Fixes: 8a37d87d ("usb: typec: Bus type for alternate modes") Cc: <stable@vger.kernel.org> Co-developed-by:
Christian A. Ehrhardt <lk@c--e.de> Signed-off-by:
RD Babiera <rdbabiera@google.com> Tested-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240103181754.2492492-2-rdbabiera@google.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
This reverts commit b17b7fe6. That commit messed up the reference counting, so it needs to be rethought. Fixes: b17b7fe6 ("usb: typec: class: fix typec_altmode_put_partner to put plugs") Cc: <stable@vger.kernel.org> Cc: RD Babiera <rdbabiera@google.com> Reported-by:
Chris Bainbridge <chris.bainbridge@gmail.com> Closes: https://lore.kernel.org/lkml/CAP-bSRb3SXpgo_BEdqZB-p1K5625fMegRZ17ZkPE1J8ZYgEHDg@mail.gmail.com/ Signed-off-by:
-
When I was creating this driver, my bright mind overlooked the existence of desc->qos_offset and decided to make up for the difference it made by adding 21 (0x15) to the port index on SNoC and its downstream buses. Undo this mistake to make the indices actually mean something. Signed-off-by:
-
Pointers to struct qcom_icc_node are const. Signed-off-by:
Andrew Halaney <ahalaney@redhat.com> Reviewed-by:
-
Remove some unnecessary includes and get rid of the abusive of_platform in favor of the correct headers. Reported-by:
Rob Herring <robh+dt@kernel.org> Reported-by:
-
Dmitry Baryshkov authored
Enable Qualcomm PMIC TCPM driver, it is used to handle Type-C ports on devices like Qualcomm Robotics RB5 platform. Signed-off-by:
-
- May 31, 2024
-
-
Dmitry Baryshkov authored
Plug in USB-C related bits and pieces to enable USB role switching and USB-C orientation handling for the Qualcomm RB1 board. Reviewed-by:
-
Dmitry Baryshkov authored
Define VBUS regulator and the Type-C handling block as present on the Quacomm PM4125 PMIC. Reviewed-by:
-
Dmitry Baryshkov authored
It seems, the only actual mentions of PM2250 can be found are related to the Qualcomm RB1 platform. However even RB1 schematics use PM4125 as a PMIC name. Rename PM2250 to PM4125 to follow the documentation. Note, this doesn't change the compatible strings. There was a previous argument regarding renaming of compat strings. Fixes: c309b9a5 ("arm64: dts: qcom: Add initial PM2250 device tree") Acked-by:
-
Dmitry Baryshkov authored
Plug in USB-C related bits and pieces to enable USB role switching and USB-C orientation handling for the Qualcomm RB2 board. Signed-off-by:
-
Dmitry Baryshkov authored
This reverts commit a442e3f3.
-
Dmitry Baryshkov authored
Revert bits of the USB configuration in preparation of adding proper USB-C support. Signed-off-by: -
Dmitry Baryshkov authored
Define VBUS regulator and the Type-C handling block as present on the Quacomm PMI632 PMIC. Reviewed-by:
-
Check and unregister existing source caps in tcpm_register_source_caps function before registering new ones. This change fixes following warning when port partner resends source caps after negotiating PD contract for the purpose of re-negotiation. [ 343.135030][ T151] sysfs: cannot create duplicate filename '/devices/virtual/usb_power_delivery/pd1/source-capabilities' [ 343.135071][ T151] Call trace: [ 343.135076][ T151] dump_backtrace+0xe8/0x108 [ 343.135099][ T151] show_stack+0x18/0x24 [ 343.135106][ T151] dump_stack_lvl+0x50/0x6c [ 343.135119][ T151] dump_stack+0x18/0x24 [ 343.135126][ T151] sysfs_create_dir_ns+0xe0/0x140 [ 343.135137][ T151] kobject_add_internal+0x228/0x424 [ 343.135146][ T151] kobject_add+0x94/0x10c [ 343.135152][ T151] device_add+0x1b0/0x4c0 [ 343.135187][ T151] device_register+0x20/0x34 [ 343.135195][ T151] usb_power_delivery_register_capabilities+0x90/0x20c [ 343.135209][ T151] tcpm_pd_rx_handler+0x9f0/0x15b8 [ 343.135216][ T151] kthread_worker_fn+0x11c/0x260 [ 343.135227][ T151] kthread+0x114/0x1bc [ 343.135235][ T151] ret_from_fork+0x10/0x20 [ 343.135265][ T151] kobject: kobject_add_internal failed for source-capabilities with -EEXIST, don't try to register things with the same name in the same directory. Fixes: 8203d269 ("usb: typec: tcpm: Register USB Power Delivery Capabilities") Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Mark Brown <broonie@kernel.org> Signed-off-by:
Amit Sunil Dhamne <amitsd@google.com> Reviewed-by:
-
When a Fast Role Swap control message attempt results in a transition to ERROR_RECOVERY, the TCPC can still queue a TCPM_SOURCING_VBUS event. If the event is queued but processed after the tcpm_reset_port() call in the PORT_RESET state, then the following occurs: 1. tcpm_reset_port() calls tcpm_init_vbus() to reset the vbus sourcing and sinking state 2. tcpm_pd_event_handler() turns VBUS on before the port is in the default state. 3. The port resolves as a sink. In the SNK_DISCOVERY state, tcpm_set_charge() cannot set vbus to charge. Clear pd events within PORT_RESET to get rid of non-applicable events. Fixes: b17dd571 ("staging: typec: tcpm: Improve role swap with non PD capable partners") Cc: stable@vger.kernel.org Signed-off-by:
-
Off-by-one errors happen because nr_snk_pdo and nr_src_pdo are incorrectly added one. The index of the loop is equal to the number of PDOs to be updated when leaving the loop and it doesn't need to be added one. When doing the power negotiation, TCPM relies on the "nr_snk_pdo" as the size of the local sink PDO array to match the Source capabilities of the partner port. If the off-by-one overflow occurs, a wrong RDO might be sent and unexpected power transfer might happen such as over voltage or over current (than expected). "nr_src_pdo" is used to set the Rp level when the port is in Source role. It is also the array size of the local Source capabilities when filling up the buffer which will be sent as the Source PDOs (such as in Power Negotiation). If the off-by-one overflow occurs, a wrong Rp level might be set and wrong Source PDOs will be sent to the partner port. This could potentially cause over current or port resets. Fixes: cd099cde ("usb: typec: tcpm: Support multiple capabilities") Cc: stable@vger.kernel.org Signed-off-by:
Kyle Tso <kyletso@google.com> Reviewed-by:
-
The PD of Type-C port needs to be updated in pd_set. Unlink the Type-C port device to the old PD before linking it to a new one. Fixes: cd099cde ("usb: typec: tcpm: Support multiple capabilities") Cc: stable@vger.kernel.org Signed-off-by:
-
When unregister pd capabilitie in tcpm, KASAN will capture below double -free issue. The root cause is the same capabilitiy will be kfreed twice, the first time is kfreed by pd_capabilities_release() and the second time is explicitly kfreed by tcpm_port_unregister_pd(). [ 3.988059] BUG: KASAN: double-free in tcpm_port_unregister_pd+0x1a4/0x3dc [ 3.995001] Free of addr ffff0008164d3000 by task kworker/u16:0/10 [ 4.001206] [ 4.002712] CPU: 2 PID: 10 Comm: kworker/u16:0 Not tainted 6.8.0-rc5-next-20240220-05616-g52728c567a55 #53 [ 4.012402] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.017569] Workqueue: events_unbound deferred_probe_work_func [ 4.023456] Call trace: [ 4.025920] dump_backtrace+0x94/0xec [ 4.029629] show_stack+0x18/0x24 [ 4.032974] dump_stack_lvl+0x78/0x90 [ 4.036675] print_report+0xfc/0x5c0 [ 4.040289] kasan_report_invalid_free+0xa0/0xc0 [ 4.044937] __kasan_slab_free+0x124/0x154 [ 4.049072] kfree+0xb4/0x1e8 [ 4.052069] tcpm_port_unregister_pd+0x1a4/0x3dc [ 4.056725] tcpm_register_port+0x1dd0/0x2558 [ 4.061121] tcpci_register_port+0x420/0x71c [ 4.065430] tcpci_probe+0x118/0x2e0 To fix the issue, this will remove kree() from tcpm_port_unregister_pd(). Fixes: cd099cde ("usb: typec: tcpm: Support multiple capabilities") cc: stable@vger.kernel.org Suggested-by:
Aisheng Dong <aisheng.dong@nxp.com> Signed-off-by:
Xu Yang <xu.yang_2@nxp.com> Acked-by:
-
In tcpm_pd_set, the array of port source capabilities is port->src_pdo, not port->snk_pdo. Fixes: cd099cde ("usb: typec: tcpm: Support multiple capabilities") Cc: stable@vger.kernel.org Signed-off-by:
-
While commit 69f89168 ("usb: typec: tpcm: Fix issues with power being removed during reset") fixes the boot issues for bus powered devices such as LibreTech Renegade Elite/Firefly, it trades off the CC pins NOT being Hi-Zed during errory recovery (i.e PORT_RESET) for devices which are NOT bus powered(a.k.a self powered). This change Hi-Zs the CC pins only for self powered devices, thus preventing brown out for bus powered devices Adhering to spec is gaining more importance due to the Common charger initiative enforced by the European Union. Quoting from the spec: 4.5.2.2.2.1 ErrorRecovery State Requirements The port shall not drive VBUS or VCONN, and shall present a high-impedance to ground (above zOPEN) on its CC1 and CC2 pins. Hi-Zing the CC pins is the inteded behavior for PORT_RESET. CC pins are set to default state after tErrorRecovery in PORT_RESET_WAIT_OFF. 4.5.2.2.2.2 Exiting From ErrorRecovery State A Sink shall transition to Unattached.SNK after tErrorRecovery. A Source shall transition to Unattached.SRC after tErrorRecovery. Fixes: 69f89168 ("usb: typec: tpcm: Fix issues with power being removed during reset") Cc: stable@vger.kernel.org Cc: Mark Brown <broonie@kernel.org> Signed-off-by:
Badhri Jagan Sridharan <badhri@google.com> Tested-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240228000512.746252-1-badhri@google.com Signed-off-by:
-
Since the merge of b717dfbf ("Revert "usb: typec: tcpm: fix cc role at port reset"") into mainline the LibreTech Renegade Elite/Firefly has died during boot, the main symptom observed in testing is a sudden stop in console output. Gábor Stefanik identified in review that the patch would cause power to be removed from devices without batteries (like this board), observing that while the patch is correct according to the spec this appears to be an oversight in the spec. Given that the change makes previously working systems unusable let's revert it, there was some discussion of identifying systems that have alternative power and implementing the standards conforming behaviour in only that case. Fixes: b717dfbf ("Revert "usb: typec: tcpm: fix cc role at port reset"") Cc: stable <stable@kernel.org> Cc: Badhri Jagan Sridharan <badhri@google.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20240212-usb-fix-renegade-v1-1-22c43c88d635@kernel.org Signed-off-by:
-
The reverted commit makes the state machine only ever go from SRC_ATTACH_WAIT to SNK_TRY in endless loop when toggling. After revert it goes to SRC_ATTACHED after initially trying SNK_TRY earlier, as it should for toggling to ever detect the power source mode and the port is again able to provide power to attached power sinks. This reverts commit 2d6d8012. Cc: stable@vger.kernel.org Fixes: 2d6d8012 ("usb: typec: tcpm: reset counter when enter into unattached state after try role") Signed-off-by:
Ondrej Jirman <megi@xff.cz> Link: https://lore.kernel.org/r/20240217162023.1719738-1-megi@xff.cz Signed-off-by:
-
