Message-ID: <Z9v/z/i6OyWXXe7N@hu-wasimn-hyd.qualcomm.com>
Date: Thu, 20 Mar 2025 17:15:19 +0530
From: Wasim Nazir <quic_wasimn@...cinc.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
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

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;
And between ride & ride-r3 ethernet is changing.
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.

We thought of using overlay as otherwise we have to create separate board
DTS to support [Ethernet-v2] cards.

> 
> > 


> >> |                                    +-------------------------+-----------------------+-------------------< sa8775p-ride-ethernet-aqr115c.dtso |
> 
> How does "sa8775p-ride-ethernet-aqr115c" hardware look like?
> 

Here sa8775p-ride-ethernet-aqr115c.dtso is representing [Ethernet-v2] card.

> 
> Several companies solved it - most of NXP vendors, many Renesas etc. I
> really do not get why this needs so much talk and you cannot learn from
> their architecture how SoM should be represented.
> 

Our SoM is separate HW which is reusable in ride-hw. Can you share more
details on what we can improve here?


Thanks & regards,
Wasim

Powered by blists - more mailing lists