public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Umang Chheda <umang.chheda@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org,
	richardcochran@gmail.com, linux-arm-msm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/4] arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi
Date: Tue, 5 May 2026 19:17:17 +0530	[thread overview]
Message-ID: <7461207d-aa05-4272-a9c0-360e6abfb0a6@oss.qualcomm.com> (raw)
In-Reply-To: <uxklfc663dzdjxd5e7gd6mftddty2nxqypoandbwakydgrjhaa@s5mskp2tlfch>

Hi Dmitry,

On 5/5/2026 4:58 AM, Dmitry Baryshkov wrote:
> On Tue, May 05, 2026 at 12:56:15AM +0530, Umang Chheda wrote:
>> Hello Dmitry,
>>
>>
>> On 5/5/2026 12:14 AM, Dmitry Baryshkov wrote:
>>> On Mon, Apr 27, 2026 at 10:35:02PM +0530, Umang Chheda wrote:
>>>> The monaco-ac EVK is a new board variant which shares the majority of
>>>> its hardware description with the existing monaco-evk board.
>>>
>>> No, this is not a good reason. Is there a common PCB? There was a long
>>> discussion for it for the Hamoa / Purwa EVK.
>>
>> PCB is not common for these 2 boards.
>>
>> Also, not sure if I mis-understood you - You had mentioned to have a
>> common file for both the variants [1] in the earlier version of patch
>> hence refactored it this way.
> 
> There was an explicit question if PCB is the same as a prerequisite for
> the unification of DTS


Thanks for the clarification.

This was discussed in the earlier v2 [1] — even though the PCB is not
common, the majority of the hardware blocks and their wiring are
functionally identical between monaco-evk and monaco-ac-evk, with only
difference in H/W being 4 PMIC in monaco-evk v/s 2 PMIC on monaco-ac-evk
and the rail which is supplied to the SDHC controller.

The intent here is to avoid duplication across the two boards rather
than imply a shared PCB, similar to what was discussed earlier.

If this approach is still not acceptable without a common PCB, can I
drop the refactoring and keep the DTS files fully separate ?

[1]
https://lore.kernel.org/all/8f79000d-ccbb-403c-871c-7a36423c9eee@oss.qualcomm.com/

> 
>>
>> [1]
>> https://lore.kernel.org/lkml/7r6373fo56alzqa4e2zzdnsgwfhgdkmbhxe4cvdo4p7fg3zren@eyiml4uedfbn/
>>
>>>
>>>>
>>>> In preparation for adding this variant, extract the common hardware
>>>> nodes from monaco-evk.dts into a new shared monaco-evk-common.dtsi
>>>> include file, and update monaco-evk.dts to include it and keep only
>>>> board-specific overrides.
>>>>
>>>> No functional change intended.
>>>>
>>>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
>>>> ---
>>>
>>
>> Thanks,
>> Umang
>>
> 

Thanks,
Umang



  reply	other threads:[~2026-05-05 13:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27 17:05 [PATCH v4 0/4] arm64: dts: qcom: Introduce support for monaco-ac-evk Umang Chheda
2026-04-27 17:05 ` [PATCH v4 1/4] arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi Umang Chheda
2026-05-04 12:57   ` Konrad Dybcio
2026-05-04 18:28     ` Umang Chheda
2026-05-04 20:19     ` Krzysztof Kozlowski
2026-05-05 13:53       ` Umang Chheda
2026-05-06  9:18         ` Konrad Dybcio
2026-05-04 18:44   ` Dmitry Baryshkov
2026-05-04 19:26     ` Umang Chheda
2026-05-04 23:28       ` Dmitry Baryshkov
2026-05-05 13:47         ` Umang Chheda [this message]
2026-04-27 17:05 ` [PATCH v4 2/4] dt-bindings: arm: qcom: Add monaco-ac-evk support Umang Chheda
2026-04-27 17:05 ` [PATCH v4 3/4] arm64: dts: qcom: monaco: Add monaco-ac EVK board Umang Chheda
2026-05-04 12:53   ` Konrad Dybcio
2026-05-04 19:16     ` Umang Chheda
2026-05-06  9:17       ` Konrad Dybcio
2026-04-27 17:05 ` [PATCH v4 4/4] arm64: dts: qcom: monaco-ac-evk: Add IFP mezzanine Umang Chheda

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=7461207d-aa05-4272-a9c0-360e6abfb0a6@oss.qualcomm.com \
    --to=umang.chheda@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@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=richardcochran@gmail.com \
    --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