Linux SOC development
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Ryan Chen <ryan_chen@aspeedtech.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Joel Stanley <joel@jms.id.au>,
	Andrew Jeffery <andrew@codeconstruct.com.au>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Nishanth Menon <nm@ti.com>,
	"nfraprado@collabora.com" <nfraprado@collabora.com>,
	Taniya Das <quic_tdas@quicinc.com>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Eric Biggers <ebiggers@google.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"soc@lists.linux.dev" <soc@lists.linux.dev>,
	Mo Elbadry <elbadrym@google.com>,
	Rom Lemarchand <romlem@google.com>,
	William Kennington <wak@google.com>,
	Yuxiao Zhang <yuxiaozhang@google.com>,
	"wthai@nvidia.com" <wthai@nvidia.com>,
	"leohu@nvidia.com" <leohu@nvidia.com>,
	"dkodihalli@nvidia.com" <dkodihalli@nvidia.com>,
	"spuranik@nvidia.com" <spuranik@nvidia.com>
Subject: Re: [PATCH v0 3/5] arm64: dts: aspeed: Add initial AST2700 SoC device tree
Date: Mon, 16 Jun 2025 12:29:38 +0200	[thread overview]
Message-ID: <ce3044aa-2b62-4516-99ff-88dcb56b128b@kernel.org> (raw)
In-Reply-To: <OS8PR06MB754181823BC03DADBF0A9B82F270A@OS8PR06MB7541.apcprd06.prod.outlook.com>

On 16/06/2025 09:52, Ryan Chen wrote:
> 
>> Subject: Re: [PATCH v0 3/5] arm64: dts: aspeed: Add initial AST2700 SoC device
>> tree
>>
>> On 16/06/2025 08:54, Ryan Chen wrote:
>>>> Subject: Re: [PATCH v0 3/5] arm64: dts: aspeed: Add initial AST2700
>>>> SoC device tree
>>>>
>>>> On 16/06/2025 08:32, Ryan Chen wrote:
>>>>>>>
>>>>>>> But I don't know your previous "NAK, never tested" mean.
>>>>>>> I did make CHECK_DTBS=y arch/arm64/boot/dts/aspeed/ don't see the
>>>>>>> fail with
>>>>>>> intc0: interrupt-controller@12100000 {
>>>>>>> 	compatible = "simple-mfd";
>>>>>>>
>>>>>>> So, could you point me more test instruction for this?
>>>>>> See syscon.yaml. And writing bindings or talks on conferences:
>>>>>> simple-mfd cannot be alone.
>>>>>>
>>>>>
>>>>>         intc0: interrupt-controller@12100000 { Sorry, do you mean
>>>>> add by following?
>>>>> 				 compatible = "aspeed,intc-controller", "simple-mfd";
>>>>>  					.....
>>>>>                  intc0_11: interrupt-controller@1b00 {
>>>>> 					compatible = "aspeed,ast2700-intc-ic";
>>>>>  					......
>>>>>                  };
>>>>>          };
>>>>
>>>> Maybe, but you said this is base address, so how can it be some
>>>> separate device?
>>>>
>>>> I mean really, don't add fake nodes just to satisfy some device instantiation.
>>>> Describe what this really is. That is the job of DTS. Not some fake nodes.
>>>
>>>
>>> Understood. Let me explain more about the hardware layout.
>>> The interrupt controller space is decoded starting from 0x12100000,
>>> which includes both a set of global configuration registers and
>>> individual interrupt controller instances.
>>>
>>> The region at 0x12100000 contains global interrupt control registers
>>> (e.g., protect config, interrupt routing etc.).
>>
>> This does not explain me why global controller registers are a BUS or MFD as
>> you claimed here.
>>>
>>> The actual interrupt controller logic starts at 0x12101b00, where each
>>> sub-controller instance (e.g., intc0_11, intc0_12, etc.) has its own set of
>> registers.
>>
>> I don't know what is a "global controller register" and "own set of registers". If
>> you have device spanning over multiple memory blocks, device takes multiple
>> 'reg' entries for example. There are many other configurations, depending on
>> real hardware and relationships. Just look at other DTS.
> 
> 
> Here are two possible representations of the interrupt controller layout for the AST2700 platform:
> Please advise which approach would be more appropriate or preferred? 
> 
> Option 1: Hierarchical representation with a parent node
> This models the entire interrupt controller registers space (start from 0x12100000), 
> where the parent node includes the global register area and acts as a container for per-instance sub-controllers:
> 
>     intc0: interrupt-controller@12100000 {
>         compatible = "aspeed,intc-controller";
>         reg = <0 0x12100000 0x4000>;
> 		...................
>         intc0_11: interrupt-controller@1b00 {
>             compatible = "aspeed,ast2700-intc-ic";
>             reg = <0x1b00 0x100>;
> 			...................        };
>     };
> And I find the others dtsi have global register use syscon ex.
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/sprd/ums512.dtsi#L177-L192
> 
> Option 2: Flat representation with only the per-domain node
> This focuses on just the interrupt controller logic at 0x12101b00, skipping the global register modeling:
> 
>     intc0_11: interrupt-controller@12101b00 {
>         compatible = "aspeed,ast2700-intc-ic";
>         reg = <0 0x12101b00 0x100>;
> 		...................
>     };
> 


I don't understand this: you already have a binding for this, you
already described the device, so why now this is being changed?

You are supposed to send complete bindings for your device (see writing
bindings). Not some half-baked parts and then half year later different
DTS which points that your bindings were just incomplete.

Look how a completely new SoC is supposed to be upstreamed, on the day
of public announcement of the hardware:

https://lore.kernel.org/all/20231121-topic-sm8650-upstream-dt-v3-0-db9d0507ffd3@linaro.org/

Are all or most bindings posted? Yes
Is DTS for all devices from above bindings posted? Yes
Do we see complete picture? Yes

I still have no clue what is global interrupt registers. I already said
it, but you keep repeating the same. I have no clue.

Why this would be a parent?

Why this would not be a parent?

Best regards,
Krzysztof

  reply	other threads:[~2025-06-16 10:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12 10:09 [PATCH v0 0/5] Add initial AST2700 SoC support Ryan Chen
2025-06-12 10:09 ` [PATCH v0 1/5] dt-bindings: arm: aspeed: Add AST2700 board compatible Ryan Chen
2025-06-12 10:15   ` Krzysztof Kozlowski
2025-06-13  2:00     ` Ryan Chen
2025-06-12 10:09 ` [PATCH v0 2/5] arm64: Kconfig: Add Aspeed SoC family (ast2700) platform option Ryan Chen
2025-06-12 10:09 ` [PATCH v0 3/5] arm64: dts: aspeed: Add initial AST2700 SoC device tree Ryan Chen
2025-06-12 10:17   ` Krzysztof Kozlowski
2025-06-13  2:29     ` Ryan Chen
2025-06-13  6:16       ` Krzysztof Kozlowski
2025-06-16  2:24         ` Ryan Chen
2025-06-16  6:15           ` Krzysztof Kozlowski
2025-06-16  6:32             ` Ryan Chen
2025-06-16  6:43               ` Krzysztof Kozlowski
2025-06-16  6:54                 ` Ryan Chen
2025-06-16  7:07                   ` Krzysztof Kozlowski
2025-06-16  7:52                     ` Ryan Chen
2025-06-16 10:29                       ` Krzysztof Kozlowski [this message]
2025-06-12 10:20   ` Krzysztof Kozlowski
2025-06-13  2:54     ` Ryan Chen
2025-06-12 10:09 ` [PATCH v0 4/5] arm64: dts: aspeed: Add AST2700 EVB " Ryan Chen
2025-06-12 10:14   ` Krzysztof Kozlowski
2025-06-12 10:14     ` Krzysztof Kozlowski
2025-06-12 10:09 ` [PATCH v0 5/5] arm64: configs: Update defconfig for AST2700 platform support Ryan Chen
2025-06-12 10:18   ` Krzysztof Kozlowski
2025-06-12 20:12 ` [PATCH v0 0/5] Add initial AST2700 SoC support Rob Herring (Arm)
2025-06-13  5:29   ` Andrew Jeffery
2025-06-25 20:42     ` Rob Herring

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=ce3044aa-2b62-4516-99ff-88dcb56b128b@kernel.org \
    --to=krzk@kernel.org \
    --cc=andrew@codeconstruct.com.au \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@oss.qualcomm.com \
    --cc=catalin.marinas@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dkodihalli@nvidia.com \
    --cc=ebiggers@google.com \
    --cc=elbadrym@google.com \
    --cc=geert@linux-m68k.org \
    --cc=joel@jms.id.au \
    --cc=krzk+dt@kernel.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=leohu@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfraprado@collabora.com \
    --cc=nm@ti.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=quic_tdas@quicinc.com \
    --cc=robh@kernel.org \
    --cc=romlem@google.com \
    --cc=ryan_chen@aspeedtech.com \
    --cc=soc@lists.linux.dev \
    --cc=spuranik@nvidia.com \
    --cc=wak@google.com \
    --cc=will@kernel.org \
    --cc=wthai@nvidia.com \
    --cc=yuxiaozhang@google.com \
    /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