From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 83004CF9C59 for ; Fri, 20 Sep 2024 16:40:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=HhhZd7ayiXHvtgpmt5boDxIP46gDlJOJ649tcx8htLw=; b=0DUa+LG3TwFBNQoOUWEe+TjYUW jBuYLT70WlLxT4NrpbO6CrMTR2NOVz7CyHmw5I5W/2c39OlaZL4N6xjY0GwwnH+wAdOPg/HUjBEuV rQ37KouWZRm05mVS+FGoex7Vy9WNRWA4UUARXlBTd97//mB0D//PtlCV+hKW6h/Pg/tFVY3/bpRfL tT5+h24ttr5tp7EjuB52WOVJDJBSX9YAVJOpQApA/hRMpUyhIQ+Mg3yuppl+UrE4A0GbLeHiq6IsC Wxjd26NF+J2ILULTqpJpurz9wfgZHOUQAfYswG9oqy68yrp8G7ZcOnV/yivLNzq0psSH87jGZQ46v mpBZP75w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1srgg3-0000000CcTt-2PtT; Fri, 20 Sep 2024 16:40:15 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1srgev-0000000CcMh-1GMa for linux-arm-kernel@lists.infradead.org; Fri, 20 Sep 2024 16:39:07 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 04F131007; Fri, 20 Sep 2024 09:39:32 -0700 (PDT) Received: from e130802.arm.com (unknown [10.57.52.210]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D9B393F64C; Fri, 20 Sep 2024 09:38:58 -0700 (PDT) Date: Fri, 20 Sep 2024 17:38:51 +0100 From: Abdellatif El Khlifi To: Krzysztof Kozlowski Cc: mathieu.poirier@linaro.org, Adam.Johnston@arm.com, Hugues.KambaMpiana@arm.com, Drew.Reed@arm.com, andersson@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org, krzysztof.kozlowski+dt@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org, liviu.dudau@arm.com, lpieralisi@kernel.org, robh@kernel.org, sudeep.holla@arm.com, robin.murphy@arm.com Subject: Re: [PATCH v2 1/5] dt-bindings: remoteproc: sse710: Add the External Systems remote processors Message-ID: <20240920163851.GA385919@e130802.arm.com> References: <20240822170951.339492-1-abdellatif.elkhlifi@arm.com> <20240822170951.339492-2-abdellatif.elkhlifi@arm.com> <20240919093517.GA43740@e130802.arm.com> <222b3b11-151a-4ad0-91ea-54ae8f280bcb@kernel.org> <20240919145741.GA7940@e130802.arm.com> <85a223e9-05a4-4034-87a5-57d3eb9409b7@kernel.org> <20240920141958.GA288724@e130802.arm.com> <7784248d-4372-4cf1-a01a-5b731b3f6b96@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7784248d-4372-4cf1-a01a-5b731b3f6b96@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240920_093905_463446_FD18FF2B X-CRM114-Status: GOOD ( 25.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Krzysztof, > >>>>>>> + '#extsys-id': > >>>>>> > >>>>>> '#' is not correct for sure, that's not a cell specifier. > >>>>>> > >>>>>> But anyway, we do not accept in general instance IDs. > >>>>> > >>>>> I'm happy to replace the instance ID with another solution. > >>>>> In our case the remoteproc instance does not have a base address > >>>>> to use. So, we can't put remoteproc@address > >>>>> > >>>>> What do you recommend in this case please ? > >>>> > >>>> Waiting one month to respond is a great way to drop all context from my > >>>> memory. The emails are not even available for me - gone from inbox. > >>>> > >>>> Bus addressing could note it. Or you have different devices, so > >>>> different compatibles. Tricky to say, because you did not describe the > >>>> hardware really and it's one month later... > >>>> > >>> > >>> Sorry for waiting. I was in holidays. > >>> > >>> I'll add more documentation about the external system for more clarity [1]. > >>> > >>> Basically, Linux runs on the Cortex-A35. The External system is a > >>> Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. > >>> It can only control Cortex-M core using the reset control and status registers mapped > >>> in the memory space of the Cortex-A35. > >> > >> That's pretty standard. > >> > >> It does not explain me why bus addressing or different compatible are > >> not sufficient here. > > > > Using an instance ID was a design choice. > > I'm happy to replace it with the use of compatible and match data (WIP). > > > > The match data will be pointing to a data structure containing the right offsets > > to be used with regmap APIs. > > > > syscon node is used to represent the Host Base System Control register area [1] > > where the external system reset registers are mapped (EXT_SYS*). > > > > The nodes will look like this: > > > > syscon@1a010000 { > > compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > > reg = <0x1a010000 0x1000>; > > > > #address-cells = <1>; > > #size-cells = <1>; > > > > remoteproc@310 { > > compatible = "arm,sse710-extsys0"; > > reg = <0x310 4>; > > Uh, why do you create device nodes for one word? This really suggests it > is part of parent device and your split is artificial. The external system registers (described by the remoteproc node) are part of the parent device (the Host Base System Control register area) described by syscon. In case of the external system 0 , its registers are located at offset 0x310 (physical address: 0x1a010310) When instantiating the devices without @address, the DTC compiler detects 2 nodes with the same name (remoteproc). syscon@1a010000 { ... remoteproc { compatible = "arm,sse710-extsys0"; ... } remoteproc { compatible = "arm,sse710-extsys1"; ... } Cheers Abdellatif