Re: [PATCH 6/6] arm64: dts: qcom: add base QCS615 RIDE dts

[Aiqun Yu (Maria)]

On 9/4/2024 6:23 PM, Konrad Dybcio wrote:
> On 4.09.2024 11:32 AM, Krzysztof Kozlowski wrote:
>> On 04/09/2024 10:35, Lijuan Gao wrote:
>>>
>>>
>>> 在 8/28/2024 5:34 PM, Krzysztof Kozlowski 写道:
>>>> On 28/08/2024 11:31, Lijuan Gao wrote:
>>>>>>>>> +/ {
>>>>>>>>> +	model = "Qualcomm Technologies, Inc. QCS615 Ride";
>>>>>>>>> +	compatible = "qcom,qcs615-ride", "qcom,qcs615";
>>>>>>>>> +
>>>>>>>>> +	chosen {
>>>>>>>>> +		bootargs = "console=hvc0";
>>>>>>>>
>>>>>>>> Noooo, last time I agreed on this, you told me later it is different.
>>>>>>>>
>>>>>>> In the early stages, enabling HVC is to more easily verify clock and
>>>>>>> PMIC related functions, as it’s difficult to debug without the console
>>>>>>> log. After the clock and PMIC are ready, we will enable the UART console.
>>>>>>
>>>>>> Working serial is supposed to be part of the early submission.
>>>>>>
>>>>> Okay, I will remove it in the next patch.
>>>>
>>>> Can you post next version with proper serial device?
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>> Hi Krzysztof,
>>>
>>> Can we use the dts without console enabled as the first version? When 
>>> the clock is ready, we will submit new changes to enable the UART console.
>>
>> It is very surprising not to have console available in the first, early
>> submission, but it is not a blocker for me.
> 
> Lijuan,
> 
> I see that the initial submission is very slim. GCC+UART+TLMM is
> usually the smallest we tend to accept.

We are exploring various ways to improve the efficiency of the upstream
change merge process. In the current QCS615 project, we are
experimenting with a slim "HVC console" verified base device tree to
minimize dependencies and enhance parallel work efficiency.

Currently, different developers are working on the same QCS615 project.
One developer is focusing on clock support for QCS615, another is
working on interconnect support, and a third is handling TLMM pinctrl
support. Additionally, the QUP UART validation depends on above soc
specific GCC clock/TLMM support.

Here is the proposed process chart for reference, Clock/TLMM, even other
functionality like LLCC can be validated apart from current Base support
with HVC console enabled:
                               +---------------+

                               | Clock         |

                               |               |

                               +---------------+

+---------------------+

|    Base support:    |        +---------------+       +-----+

| HVC console enabled |------> | TLMM          | ----->| UART|

+---------------------+        +---------------+       +-----+



                               +---------------+

                               | Interconnect  |

                               +---------------+


It is suggested to have process like this:
1. Have hvc console enabled base device tree support.
2. TLMM/GCC/Interconnect/LLCC/etc drivers can be pushed along with the
needful dt changes.
3. QUP uart support change after TLMM/GCC dependency uploaded.

Here is an original example of qcs8300 project that the base device tree
wait until have all qup uart enabled support for reference:
1. The first soc support[1] pushed at 08/14.
2. TLMM support[2] pushed at 08/19.
3. GCC clock support[3] pushed at 08/20.
4. Interconnect support[4] pushed at 08/27.
5. LLCC support[5] pushed at 09/03.
6. Initial device tree support[6] pushed at 09/04. And it have 5
co-developer in the initial device tree support.


[1]https://lore.kernel.org/all/20240814072806.4107079-1-quic_jingyw@xxxxxxxxxxx/
[2]https://lore.kernel.org/all/20240819064933.1778204-1-quic_jingyw@xxxxxxxxxxx/
[3]https://lore.kernel.org/all/20240820-qcs8300-gcc-v1-0-d81720517a82@xxxxxxxxxxx/
[4]https://lore.kernel.org/all/20240827151622.305-1-quic_rlaggysh@xxxxxxxxxxx/
[5]https://lore.kernel.org/all/20240903-qcs8300_llcc_driver-v1-0-228659bdf067@xxxxxxxxxxx/
> 
> While hooking up these drivers may take some time, please consider
> at least describing a subset of the clocks and the QUP UART, as
> everything non-SoC-specific is already in place.

To be more specific, are you suggesting like adding the base device tree
describing with current nodes subset which only have non-soc-specific
info, like:
1. "apps_rsc" nodes without info of
"qcom,qcs615-rpmh-clk","qcom,qcs615-gcc"?
2."qcom,geni-debug-uart" nodes description without the clock properties?

> 
> Konrad

-- 
Thx and BRs,
Aiqun(Maria) Yu