linux-yocto: enable display on QCM6490 IDP board #593
Conversation
Add support for the Novatek NT36672E LCD DSI panel driver. Signed-off-by: Srihitha Tangudu <quic_tangudu@quicinc.com>
Enable CONFIG_DRM_PANEL_NOVATEK_NT36672E=y and CONFIG_BACKLIGHT_PWM=y instead of being selected as modules to fix bootup to shell. Signed-off-by: Srihitha Tangudu <quic_tangudu@quicinc.com>
Make PM7250B SID configurable, add support for PM7250B PMIC and definition for three LEDs on QCM6490 IDP board. Signed-off-by: Srihitha Tangudu <quic_tangudu@quicinc.com>
Enable display subsystem on QCM6490 IDP board. Signed-off-by: Srihitha Tangudu <quic_tangudu@quicinc.com>
Disable GPU to avoid below adreno errors during display commit as there is no plan to enable GPU rendering on QCM6490 IDP board. msm_dpu ae01000.display-controller: Direct firmware load for qcom/a660_sqe.fw failed with error -2 msm_dpu ae01000.display-controller: [drm:adreno_request_fw] *ERROR* failed to load a660_sqe.fw Signed-off-by: Srihitha Tangudu <quic_tangudu@quicinc.com>
| + struct nt36672e_panel *ctx = mipi_dsi_get_drvdata(dsi); | ||
| + | ||
| + mipi_dsi_detach(ctx->dsi); | ||
| + mipi_dsi_device_unregister(ctx->dsi); |
There was a problem hiding this comment.
There were fixups for this driver. Please pick them up too.
There was a problem hiding this comment.
Sure, will pick them in the next patch.
| CONFIG_BACKLIGHT_PWM=m | ||
| CONFIG_DRM_PANEL_NOVATEK_NT36672E=m | ||
| CONFIG_BACKLIGHT_PWM=y | ||
| CONFIG_DRM_PANEL_NOVATEK_NT36672E=y |
There was a problem hiding this comment.
Please describe the issue that you have and how does this fix the issue?
There was a problem hiding this comment.
With the above configs set to m, when I tried initially it was working. But later on I found that on multiple reboots, it's not working most of the time. But when the above configs are set as y, the device boots to shell consistently. In the failure case, the device is getting stuck before UFS enumeration and hence the panel and backlight modules are not loaded.
DSI PHY supply(vreg_l10c_0p88) is shared among UFS and USB as well. We tried below experiments suspecting it is a shared resource issue:
- As the UFS enumeration is not happening, we tried removing the PHY supply reference from the driver, the PHY probe is going ahead, but the issue is still there.
- We removed disable vote on the PHY supply but the issue persists.
So, it's not related to the shared supply between DSI PHY and UFS.
Below are the last set of logs in the failure case:
[ 1.824887] platform ae01000.display-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/dsi@ae94000
[ 1.837031] platform ae01000.display-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/dsi@ae94000
[ 1.848618] platform ae94000.dsi: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/dsi@ae94000/panel@0
[ 1.859535] platform ae94000.dsi: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/display-controller@ae01000
[ 1.874211] msm_dsi ae94000.dsi: supply refgen not found, using dummy regulator
[ 1.882201] msm_dsi ae94000.dsi: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/dsi@ae94000/panel@0
[ 1.893073] mipi-dsi ae94000.dsi.0: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/dsi@ae94000
[ 1.904303] printk: console [netcon0] enabled
[ 1.908812] netconsole: network logging started
[ 1.919298] clk: Disabling unused clocks
[ 2.028658] scsi 0:0:0:49488: Well-known LUN MICRON MT256GARAT4U313Q 0104 PQ: 0 ANSI: 6
[ 2.041892] scsi 0:0:0:49476: Well-known LUN MICRON MT256GARAT4U313Q 0104 PQ: 0 ANSI: 6
[ 2.052772] scsi 0:0:0:49456: Well-known LUN MICRON MT256GARAT4U313Q 0104 PQ: 0 ANSI: 6
I tried debugging but I didn't get any breakthrough, so we decided to go with y.
There was a problem hiding this comment.
This doesn't answer the question, why it is not working. So, the issue needs to be debugged and solved properly.
There was a problem hiding this comment.
Please consider discussing the topic with the UFS team and with @Mani-Sadhasivam , upstream ufs-qcom maintainer. Anyway, building the panel to the kernel is not a proper fix for the UFS issue.
| no plan to enable GPU rendering in near future on QCM6490 IDP board. | ||
|
|
||
| Signed-off-by: Srihitha Tangudu <quic_tangudu@quicinc.com> | ||
| Upstream-Status: Denied [https://lore.kernel.org/all/99a9a562-9f6f-411c-be1c-0a28fc2524dd@quicinc.com/] |
There was a problem hiding this comment.
Simply: NAK. The GPU is present onboard, so there is no need to disable it.
There was a problem hiding this comment.
Moreover, per Ritesh's email this patch is not necessary at all. GPU works on this platform.
There was a problem hiding this comment.
Few of the Conrad's Adreno 643+ fixes are yet to be backported. We are in discussion with our GPU team regarding the same and adreno firmware loading enablement.
There was a problem hiding this comment.
GPU on SC7280 has been supported upstream since 5.16. ZAP shader has been supported for ages. I fail to see what is so special about the QCM6490 which is supposed to be very close to SC7280.
There was a problem hiding this comment.
So, yes, please backport the patches and provide the firmware for the board.
DP is currently not planned and hence not enabled. |
DP is present on the board. The patches are available for the feature. Please pick them or provide a good reason to ignore them ('not planned' is not a good reason to leave users with the disabled feature for which the support has been implemented already). |
|
@TanguduSrihitha Please excuse me, I got confused between IDP and RB3g2. There were no DisplayPort patches, so this is fine. Please fix the remaining issues:
|
|
@TanguduSrihitha any updates? |
|
@adhudase @TanguduSrihitha another ping. |
Add support for PM7250B PMIC, Novatek NT36672E DSI panel and enable display subsystem on QCM6490 IDP board.