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

linux-yocto: enable display on QCM6490 IDP board #593

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

TanguduSrihitha
Copy link
Contributor

Add support for PM7250B PMIC, Novatek NT36672E DSI panel and enable display subsystem on QCM6490 IDP board.

Add support for the Novatek NT36672E LCD DSI panel driver.

Signed-off-by: Srihitha Tangudu <[email protected]>
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 <[email protected]>
Make PM7250B SID configurable, add support for PM7250B PMIC
and definition for three LEDs on QCM6490 IDP board.

Signed-off-by: Srihitha Tangudu <[email protected]>
Enable display subsystem on QCM6490 IDP board.

Signed-off-by: Srihitha Tangudu <[email protected]>
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 <[email protected]>
Copy link
Collaborator

@lumag lumag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also pick up the DP changes from the list.

+ struct nt36672e_panel *ctx = mipi_dsi_get_drvdata(dsi);
+
+ mipi_dsi_detach(ctx->dsi);
+ mipi_dsi_device_unregister(ctx->dsi);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There were fixups for this driver. Please pick them up too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please describe the issue that you have and how does this fix the issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. 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.
  2. 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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't answer the question, why it is not working. So, the issue needs to be debugged and solved properly.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 <[email protected]>
Upstream-Status: Denied [https://lore.kernel.org/all/[email protected]/]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simply: NAK. The GPU is present onboard, so there is no need to disable it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moreover, per Ritesh's email this patch is not necessary at all. GPU works on this platform.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, yes, please backport the patches and provide the firmware for the board.

@TanguduSrihitha
Copy link
Contributor Author

Please also pick up the DP changes from the list.

DP is currently not planned and hence not enabled.

@lumag
Copy link
Collaborator

lumag commented May 20, 2024

@TanguduSrihitha

Please also pick up the DP changes from the list.

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).

@lumag
Copy link
Collaborator

lumag commented May 21, 2024

@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:

  • GPU node disablement
  • missing panel driver fixes
  • explanation for config changes

@lumag
Copy link
Collaborator

lumag commented Jun 20, 2024

@TanguduSrihitha any updates?

@lumag
Copy link
Collaborator

lumag commented Jul 1, 2024

@adhudase @TanguduSrihitha another ping.

@TanguduSrihitha
Copy link
Contributor Author

Hi @lumag, sorry for the delay in response.

1) Compiling panel and PWM as modules: We have worked with the internal stability team and got forced crash dumps when the device is stuck. Many debug configs are not enabled by default and it took multiple iterations for us to get a parsable dump. From the tasks list and stack traces of the parsed dump, we found that the device is going into a deadlock due to clk prepare_lock MUTEX. We are working with the internal clock team to identify the root cause.

2) Missing panel driver fixes: I'll update in the next patch once we conclude on the panel and PWM configs setting.

3) Backporting of Conrad's fixes and Adreno firmware loading enablement: The GPU team is currently busy with Lemans and they'll consider support on 0.0/meta-qcom post that, probably after 7/15.

@lumag
Copy link
Collaborator

lumag commented Aug 19, 2024

@TanguduSrihitha any updates? We are past 15th of August.

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.

2 participants