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: add support for QCM6490 RB3 board #541

Merged
merged 18 commits into from
Nov 21, 2023

Conversation

adhudase
Copy link
Contributor

Add necessary configuration and kernel changes to the linux-yocto recipe to enable support for Qualcomm QCM6490 RB3 board.

This enables boot to shell on QCM6490 RB3 board with initramfs.

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.

I performed both -yocto and patch review.
The largest issue is the split. You have submitted a lot of changes in a single chunk. Instead split them into single atomic commits doing just a single item: patch linux-yocto, change machine config, etc.

Second. Please split your 26-patch series into smaller chunks too. You have a mixture of boards support, generic changes, temporary changes, debugging changes, etc.
For example, if you take away the patch 10 (definitely a temporary BSP item), it should not cause any changes to e.g. dma-heap patches.

conf/machine/qcom-armv8a.conf Outdated Show resolved Hide resolved
conf/machine/qcom-armv8a.conf Outdated Show resolved Hide resolved
bootloader for QC6490 RB3 Platform.

This commit will be reverted once voltage voting support is added
in USB driver.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah. I think I now understand your issue. Please change the min and max values to the values that are able to sustain the USB.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, we'll update min and max values.

+ <GCC_MSS_OFFLINE_AXI_CLK>, <GCC_MSS_SNOC_AXI_CLK>,
+ <GCC_MSS_Q6_MEMNOC_AXI_CLK>, <GCC_MSS_Q6SS_BOOT_CLK_SRC>,
+ <GCC_SEC_CTRL_CLK_SRC>, <GCC_WPSS_AHB_CLK>,
+ <GCC_WPSS_AHB_BDG_MST_CLK>, <GCC_WPSS_RSCP_CLK>;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ugh. The qcm6490-fairphone-fp5 lists less clocks here. Is there any reason for that?

@lumag
Copy link
Collaborator

lumag commented Nov 14, 2023

For the patch-related comments. You don't have to fix issues that I pointed out for the patch contents. Please pass them to your kernel team. However please fix the patch formatting issues (tags, etc).

@lumag
Copy link
Collaborator

lumag commented Nov 16, 2023

  • Drop the merge and revert, please. We do not have a requirement that you start at the top of the tree.
  • Split the patchset into separate series. I literally mean that. Separate subdirs, that will probably make life easier (and will also simplify handling of the patches). The patches 01-26 do not look like a separate series.

@adhudase
Copy link
Contributor Author

adhudase commented Nov 17, 2023

Sorry, this seems getting dirty. Can we close this request and create new one? Thanks

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 move series to subdirs to ease maintenance.

Other than that, few minor comments left.

conf/machine/qcom-armv8a.conf Show resolved Hide resolved
From: Luca Weiss <luca.weiss@fairphone.com>
Date: Thu, 5 Oct 2023 16:47:31 +0530
Subject: [PATCH 01/26] FROMLIST: arm64: dts: qcom: Use QCOM_SCM_VMID defines
for qcom,vmid
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is still /26. So the series looks incomplete now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ah! sorry, will correct and re-post.

@adhudase
Copy link
Contributor Author

By subdirs, do you mean something like devicetree, bindings, drivers etc.? or something like - boards support, generic changes, temporary changes, debugging changes, etc. you mentioned earlier?

@lumag
Copy link
Collaborator

lumag commented Nov 17, 2023

By subdirs, do you mean something like devicetree, bindings, drivers etc.? or something like - boards support, generic changes, temporary changes, debugging changes, etc. you mentioned earlier?

Yes. So that each group of patches is visually distinct.

@adhudase
Copy link
Contributor Author

I've created these four subdirs -
common-platform,
idp, rb3gen2,
generic-kernel-6.5

if this looks okay, I can push the patches.

@lumag
Copy link
Collaborator

lumag commented Nov 19, 2023

generic-kernel-6.5

common-platform,
idp, rb3gen2,
generic-kernel-6.5

Well, generic-kernel-6.5 defintely doesn't look ok. Upgrading to 6.6 would cause unnecessary renames.
I'd propose something simpler:

  • generic-drivers
  • qcm6490-drivers
  • qcm6490-dtsi
  • qcm6490-board-dts
  • hacks (all temporary and workaround patches go to this subdir).

@adhudase adhudase force-pushed the qcm6490_rb3 branch 2 times, most recently from cadaa77 to 49bb21c Compare November 20, 2023 17:13
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.

Now that the series are sorted out, coud you pelase reorder into the sensible order:

  • generic-drivers
  • qcm6490-drivers
  • qcm6490-dtsi
  • qcm6490-board-dts
  • hacks

Add proper kref handling on dma-buf heaps.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Add SC7280 specific register layout and table configs.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Enable the force mem core for UFS ICE clock. Update the gdsc
transition delays to the recommended values for functional correctness.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
On certain targets the PLL configuration should be skipped, thus add a
device property to support the same.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
platform.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Add UFS support for sc7280 boards.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
QCOM UFS host controller requires interconnect path configuration
for proper working. So add them for SC7280 SoC.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Certain clocks are not accessible on QCM6490 board and thus require them
to be marked protected.
Also disable the LPASS nodes which are not to be used.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Document the qcom,qcm6490-idp board based off qcm6490 SoC.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Add device tree file for Robotics RB3 Gen2 board for qcm6490 SoC.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
@hashim-shiraz
Copy link

Now that the series are sorted out, coud you pelase reorder into the sensible order:

  • generic-drivers
  • qcm6490-drivers
  • qcm6490-dtsi
  • qcm6490-board-dts
  • hacks

Can we have an alternate name for hacks which I guess would raise questions. How about workarounds (or any other name) ?

@lumag
Copy link
Collaborator

lumag commented Nov 21, 2023

Can we have an alternate name for hacks which I guess would raise questions. How about workarounds (or any other name) ?

Sure, why not.

Add board-id and msm-id for QCM6490 IDP and RB3 platform as a workaround
for picking correct DTB.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Disable sdhc1 for QCM6490 for ufs boot target to avoid probe
for sdhc1 as vreg_l7b_2p9 is shared regulator for both ufs vcc
and emmc vcc. Currently this is causing probe failure for ufs.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
UFS rails have different voltage requirement for UFS2.x v/s UFS3.x.
Bootloader sets the proper voltage based on UFS type. There can be
case where the voltage set by bootloader is overridden by HLOS client.

To prevent above issue, Add change to remove voltage voting support
for UFS rails.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
USB driver does not vote for voltage on hsphy and ssphy
rails. Due to which the initial voltage set by bootloader
is overridden by regulator framework with min voltage specified
on regulator registration.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Add QCM6940 specific kernel configs to support QCM6940 IDP and RB3 Gen2
boards on linux-yocto.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Add configuration to support Qualcomm QCM6490 IDP and Robotics RB3 Gen2
boards for yocto-linux.

QCM6490 IDP is an internal platform, similar to RB3 board,
used by most of the internal developers.

Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
@lumag lumag merged commit ec4776e into Linaro:master Nov 21, 2023
2 checks passed
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.

None yet

4 participants