Message-ID: <b46aad11-4787-49f9-ab4e-1737e583622f@kernel.org>
Date: Sat, 29 Mar 2025 05:48:00 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Wasim Nazir <quic_wasimn@...cinc.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, kernel@...cinc.com
Subject: Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride &
 Ride-r3

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

Powered by blists - more mailing lists