From: William Bright <william.bright@imd-tec.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
Date: Mon, 29 Jun 2026 11:25:30 +0100 [thread overview]
Message-ID: <akJIGk8BEgHQrt34@will-Legion-Slim-5-16APH8> (raw)
In-Reply-To: <8afbc9f9-15ff-4b60-9a0f-845f903d3c9a@oss.qualcomm.com>
On Fri, Jun 26, 2026 at 05:18:20PM +0200, Konrad Dybcio wrote:
> > +&gpu_zap_shader {
> > + firmware-name = "qcom/sm8550/a740_zap.mbn";
> > + /* Zap shader doesn't load so is disabled */
>
> If your SoC is production fused, you must provide your own ZAP firmware
> that's signed by you. Conversely, if you have a software stack that
> does not include the Gunyah hypervisor, this is likely not necessary
I solved the zap shader failing to load a couple of days ago. U-boot
wasn't fixing up DT memory node correctly so I will enable the zap
shader in V5.
> > + status = "disabled";
> > +};
> > +
> > +&i2c_master_hub_0 {
> > + status = "okay";
> > +};
> > +
> > +&i2c_hub_2 {
> > + clock-frequency = <400000>;
> > + status = "okay";
>
> nit: let's keep a \n before status, everywhere
>
> [...]
>
Ack all of your above feedback regarding formatting, new lines and
ordering.
> > +
> > + sd_vset_default: sd-vset-default-state {
> > + sd-vset-pins {
> > + pins = "gpio4";
> > + function = "gpio";
> > + drive-strength = <16>;
> > + bias-disable;
> > + };
> > + };
> > +
> > + /*
> > + * Drive LAN743x reset high (de-asserted) when pcie1 probes,
> > + * so the PHY enumerates on the bus.
> > + */
> > + gbe_reset_default: gbe-reset-default-state {
> > + pins = "gpio138";
> > + function = "gpio";
> > + drive-strength = <2>;
> > + bias-disable;
> > + output-high;
> > + };
> > +
> > + /*
> > + * We drive this GPIO physically high on the M2 Key-E connector
> > + * to make sure the module is enabled. An M2 Key-E module could
> > + * be using this pin as a chip enable.
> > + */
> > + m2e_sdio_resetn_default: m2e-sdio-resetn-default-state {
> > + pins = "gpio41";
> > + function = "gpio";
> > + drive-strength = <2>;
> > + bias-disable;
> > + output-high;
> > + };
> > +
> > + /* Force the on-board PCIe switch to select the GbE upstream
> > + * port.
> > + */
> > + pcie_switch_sel_default: pcie-switch-sel-default-state {
> > + pins = "gpio16";
> > + function = "gpio";
> > + drive-strength = <2>;
> > + bias-disable;
> > + output-low;
> > + };
>
> Normally this would be handled via an actual driver - see e.g.
>
> Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
> https://lore.kernel.org/linux-arm-msm/20260605010022.968612-1-elder@riscstar.com/
>
> Konrad
>
The PCIe switch we are using is a NXP CBTU02044HEJ, this is a simple
1->2 switch that is not PCIe enumerable. Given that there isn't support
for this IC already in the kernel and that it will take quite a few
weeks/months for me to cobble something together, I am thinking that it
might make sense to drop PCIe support from this patch-series in V5 and
then submit a seperate patch-series with a driver and bindings for this
IC whenever I get something working. Are you OK with this?
> > +&usb_1 {
> > + /delete-property/ usb-role-switch;
> > + dr_mode = "peripheral";
>
> Is it really peripheral-only?
>
> Konrad
On the SBC we have a TUSB321 for role and orientation detection. I will
add this into the DT in V5 so that both roles are supported.
Thanks again for your feedback,
Will
next prev parent reply other threads:[~2026-06-29 10:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 8:57 [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
2026-06-10 8:57 ` [PATCH v4 1/4] dt-bindings: vendor-prefixes: Add IMDT William Bright
2026-06-10 8:57 ` [PATCH v4 2/4] dt-bindings: arm: qcom: Document IMDT QCS8550 SBC/SoM William Bright
2026-06-10 8:57 ` [PATCH v4 3/4] arm64: dts: qcom: Add IMDT QCS8550 SoM William Bright
2026-06-26 15:08 ` Konrad Dybcio
2026-06-10 8:57 ` [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
2026-06-10 9:05 ` sashiko-bot
2026-06-26 15:18 ` Konrad Dybcio
2026-06-29 10:25 ` William Bright [this message]
2026-06-29 14:03 ` Konrad Dybcio
2026-06-30 15:04 ` William Bright
2026-06-24 13:34 ` [PATCH v4 0/4] " William Bright
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=akJIGk8BEgHQrt34@will-Legion-Slim-5-16APH8 \
--to=william.bright@imd-tec.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox