Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

From: Krzysztof Kozlowski
Date: Sat Mar 29 2025 - 00:48:17 EST


On 20/03/2025 12:45, Wasim Nazir wrote:
> Hi Krzysztof,
>
>>>>
>>>> Which piece of actual hardware is represented in qcom-ride-common?
>>>>
>>>
>>> All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc.
>>
>> No, I asked about the name of the hardware, datasheet, ID or picture.
>> Common DTSI represents somoething, not just because you wanted to add
>> something you had in downstream.
>>
>
> Currently we don't have any datasheet or document which is publicly
> available, so I will try my best to describe our HW.
>
> Ride is a modular hardware system with several smaller daughter cards
> connected to single backplane board and each daughter card is stacked on
> top of each other. I will try to explain each daughter card with HW
> components and how it is connected to construct the ride-hw.
>
> Backplane board:
> - It contains an MCU (Aurix TC397), CAN/LIN transceiver,
> Audio/GNSS/IMU-I2C signals, Fan header
> - It holds & connects all the daughter cards.
>
> SoC card:
> - It contains:
> - SoM:
> - One of QCS9075M/QCS9100M/QAM8775p SoM.
> - Each SoM is composed of either qcs9075/qcs9100/sa8775p SoC, along
> with DDR & PMICs.
> - Each SoM can be mounted to same SoC-daughter card of ride-hw.
> - In addition to SoM, it also has
> - 4x UART, 2x USB 3.1 & 1x USB 2.0
> - Memory: 1x OSPI, 2x UFS-3.1
> - Debug: JTAG/QDSS header
> - PCIe0, PCIe1 & Display signals
> - Reset button
> - It is connected to backplain board via B2B connector.
>
> Display card:
> - It contains:
> - 4 eDP ports & 2 DSI-DP bridge
> - I2C GPIO expander & I2C switch
> - It is connected to SoC-card via B2B connector.
>
> Camera card:
> - It contains:
> - 4 Quad DE-serializer, each supporting 4 MIPI CSI inputs
> - Total upto 16 Cameras ports are supported.
> - It is connected to backplain board via B2B connector.
>
> Ethernet card:
> - There are two variants of ethernet card each with different
> capabilities:
> - [Ethernet-v1] card contains:
> - 2x 1G RGMII phy, 2x 1G SGMII phy(enabled currently)
> - Total 4 phy supported, only 2 phy are enabled and it is used in
> ride.
> - [Ethernet-v2] card contains:
> - 2x 1G RGMII phy, 2x 2.5G HSGMII(enabled currently) & 10G PCIe based
> MAC+PHY controller
> - Total 5 phy supported, only 2 phy are enabled and it is used in
> ride-r3.
> - Either [Ethernet-v1] or [Ethernet-v2] is connected to backplain board
> via B2B connector.
>
> PCIe card:
> - It contains:
> - PCIe connections to SoC-card
> - NVME, 2x WLBT module QCA6696/QCA6698 (Wi-Fi & bluetooth solution) &
> GNSS module
> - It is connected to backplain board via B2B connector & PCIe signals are
> connected to SoC card via flyover cables.
>
> Sensor Card:
> - It contains 3-Axix compass & 6-Axis 3D IMU (accel/gyro) module which
> are communicating via I2C
> - It is connected to backplain board via B2B connector.
>
> Front panel card:
> - It does not contain any active circuitry, only ports are available
> - Audio-in/out ports
> - USB hub ports
> - CAN/LIN ports
> - 12V power off switch
> - It is connected to backplain board via ribbon cable.
>
>>
>>>
>
>>>> | | | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi |
>>
>>
>> There is no ride-common hardware. If there is, send us any proof of its
>> existence. all your statements here show you want to create some
>> structure because you like it. I don't think you get my questions. You
>> painted diagram of DTS, not hardware.
>>
>> We talk about hardware. Not your DTS. Drop all DTSI, DTS, DTSO from here
>> and show us the hardware.
>>
>
> Considering outlined h/w description, following are ride configuration
> variation each platform supporting:
>
> Between qcs9075, qcs9100 & sa8775p ride/ride-r3 boards, SoM is changing;

Define these as SoMs then.

> And between ride & ride-r3 ethernet is changing.

Different ethernet cards can be also represented as cards - their own
DTSI. But there is no soc-card with one or other ethernet, so do not
create fake structure just because downstream had it.


> Excluding these differences all other cards i.e SoC, display, camera, PCIe,
> sensor, front & backplain are same and are refactored in ride-common.
> If any variant of these cards comes up in future we need to refactor
> ride-common accordingly. I will try to outline this as clearly as possible
> in next commit log.
>
> Considering current outlines of all daughter cards, following defines
> ride/ride-r3 variant boards:
> - sa8775p ride : QAM8775p SoM + [Ethernet-v1] + other daughter cards
> - sa8775p ride-r3 : QAM8775p SoM + [Ethernet-v2] + other daughter cards
> - qcs9100 ride-r3 : QCS9100M SoM + [Ethernet-v2] + other daughter cards
> - qcs9075 ride-r3 : QCS9075M SoM + [Ethernet-v2] + other daughter cards
>
> Since we don't have a document yet which formally describes
> qcs9075/qcs9100 ride board with [Ethernet-v1] card, I shall be dropping
> this particular variant in next patch series and re-send after complete
> documentation is available.
>
>>> Actually we are not including dts here instead *.dtso file will be
>>> overlayed to *-ride.dts to generate *-ride-r3.dts.
>>>
>>> Below is the correct arrow sequence.
>>
>> And the overlay represents what exactly? Different board? No, that's not
>> how overlays should be used.
>>
>> You have different board, you have different DTS.
>>
>
> No the overlay is not a different ride board. This overlay represents
> [Ethernet-v2] card which is different than [Ethernet-v1] card.

Different cards is not an overlay. Overlay is for added cards, but you
replace here the card.

Best regards,
Krzysztof